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1 Motivations and Background (s) 

As often reported i n the specialist literature in the last thirty years or so, and 



even recently (e . g., Lvvtinen and Robev . 19991 : Shapiro . 2005 ; Pan et al . 2008 ; 
Warkentin et all . l2009h with a tinge of disgruntled resignation, approximately 



half to two-thirds (if not more) Information Systems (IS) projects fail. Of course, 
there is little comfort in that thi s seems la r gely due to organizational and social , 



rather than technical factors (Pan et a,. 



ar gely due to or ganizati onal ana social, 
3, 120081 iKaplan and Harris-Salamonel 



2009). Indeed, this strikes even more in light of the almost universal recog- 



nition that the practice of information systems development has undergone in 
this lapse of time a radical transformation and has abandoned naive strictly 
structured life cycle methods of development toward more flexible, dynamic 
and multidisciplinary approaches; if this is true it is probably also because some 
principles and sensibilities typical within the HCI, CSCW and PD fields have 
so to say "trickl ed down" in the "consciousness" of IT practition ers in the "real" 
world (cf. e.g., IShapirol [iooj iFitzpatrick and Ellingseni . |2012| )). 



Among the papers that try to go beyond both the typical optimism of the 
Titanic designers^ and the fatalistic attitudes of the technological Cassandras, 



"This manuscript is the extended draft of the Chapter entitled "Building Socially Embedded 
Technologies: Implications on Design." that has been submitted for review and publication in 
Designing Socially Embedded Technologies: A European Challenge, a book edited by David 
Randall, Kjeld Schmidt, and Volker Wulf, forthcoming. 

lr To this regard, we would like to notice that one of those designers, Edward Wilding, em- 
barked at the Titanic Quarter, the place where the famous liner had been built in Belfast, and 
disembarked at Southampton 28 hours later, before the liner actually embarked its 3,000 pas- 
sengers and began its maiden voyage; while another one, Thomas Andrews, was among those 
passengers and went down with the Titanic trying to heroically rescue as many passengers as 
he could (and probably refusing to flee to safety himself). These two stories, once they have 
been moved to a purely symbolic level, in terms of Wildingism and Andrewism, can be taken 
as archetypes of different attitudes of designers in relation to "their" systems: who abandons 
the system soon after the "sea trials"; and who succumbs in the vain attempt to save its users. 
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we lik e to mention a relatively underrated one, where Harris and Henderson! 
(1999) make the point that "while our hardware technology has improved by 
orders of magnitude, and our software has grown comparably more complex, 
the relationship between people (individually or in groups) and computers has 
only improved incrementally. In some cases, it has even deteriorated''' (p. 88, 
our emphasis). They suggestively address the reason why it is so difficult "to 
translate [research insights] into comparable improvements in the usability (and 
more generally, the social integration) of computers" by advocating the adop- 
tion of a "better mythology for System Design" in alternative to the standard 
mythology. This latter encompasses a set of "myths'o, i.e., stories that empha- 
size particular aspects of the practice of IT development and all together do 
not drive practice in any strong sense; rather "shape it by helping each par- 
ticipant co nstruct and frame their accou nt of their practice". The "standard 
mythology" Harris and Henderson ( 1999h outline is rooted in the assumptions 
that: 



• The parts of the system must interact according to a pre-established 
harmony defined during its design. 

• The job of a designer is to discover, clarify, and when necessary invent the 
rules that define that harmony, and then embed them into the computer 
system. 

• The users must interact with the system in terms of the language or on- 
tology that these rules create. 



These are in a nutshell the main assumptions underlying the traditional 
"mythology of professional design". This mythology sustains the very idea of a 
conceptual process that is carried out by experts (in designing) with the par- 
ticipation of experts (in their own practices) in order to represent and direct 
the unfolding of the production o f computer -based information systems in an 
orderly manner in face of Chaos (|AA.L l200lh . The main merit of this kind of 



contributions is to let some given-for-granted assumptions surface once again 
and be object of further review and discussion. In fact, only when "the limited 
and inaccurate perspective on work and technology imposed by the standard 
myths of both organization and system design [have been recognized] , we can 
start to search for more effective approaches and write better myths around 
them". 

In this chapter we also will try to submit a sort of paralogy (|LvotardlH986h , 



or little contrarian mythology, in which to write abo ut other myths tha t could 
help us tackle the wicked problem of s ystem design ( Fitzpatrickl. 20031 p. 4). 



Although we also agree with the tenets Harris and Henderson ( 19991 ) proposed 



within their "mythology for the long term" almost fifteen years agcQ in our 
little contrarian mythology we will go a step further (right in virtue of the time 



2 Here and in the following, the word myth is not opposed to any truth fact, but it is 
rather used as synonym of "archetypical story" to indicate one possible stance, among many 
other as much as legitimate and reasonable ones. On the other hand, we keep using the term 
mythology for its powerful and evocative connota tion, although probably the most indicated 
term would be "metanarrative", in the sense after [Lyot aid (f983). 

3 Although the interested reader can refer to the original paper, we here summarize the main 
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passed in the meanwhile) by arguing around the idea that the very conception 
of design that we are all well used to (and many of us also are fond of) should 
be challenged, and indeed considered one of the most decisive factors leading to 
manifest failurfl 

If this hypothesis is true, there can be many reasons to account for it, which 
we will not investigate as not related with the chapter's aims. Our conjecture 
is that this idea of design is too disconnected from practice, although it heavily 
relies on even complicated representations of this latter, and it is nourished as 
the central element of a reductionistic framework where the process of system 
development - a word that until the industrial 19th century denoted a con- 
tinuous unfolding of things till their maturity - is rationally phased down in 
sub-components that are ontologically distinct, and where responsibilities are 
assigned on the basis of nominal competencies somehow reified in terms of spe- 
cialized roles. We are aware that a rational and engineering approach is not bad 
per se, but we submit that it reflects a conceptualization of "what complex is" 
and "what to cope with complexity means" that, as we will see in Section [3] can 
tap in false assumptions and bring to ungrounded expectation^. 

Thus, however imprudent this hypothesis may seem, we will take it seriously 
in order to submit the idea that such a conception (and the related professional 
activity) is not really necessary to build any successful computational, material 
artifact with which users have to interact to have their work done, and to propose 
an alternative approach that could do without formal or conceptual design and 
indeed any distinction between design and use (especially when this distinction 
come along with a supremac y of the f o rmer) . 



As we discussed also in (jCabitzal . 120111 ). we limit ourselves to contesting 



the necessity and primacy of conceptual design in the development of compu- 
tational interactive applications and information systems to be embedded in 
a social cooperative setting. With design we then denote the specific phase 
of the larger process in which professional analysts meet some (or many) user 
representatives and/or their managers to draw more or less formal models of 
how work is and should be accomplished, produce detailed specifications of 
the needs of the various stakeholders involved, and of how the computational 
system will support work to fulfil needs and expectations. Thus, although we 
take this term in a quite broadly meaning that encompasses business anal- 
ysis, requirement elicitation, conceptual modelling, process (re)design, spec- 
ification formalization and analysis, in what follows we will use the general 



high-l evel recommendations contained in the mythology proposed by Harris and Henderson 
(1999): that we should i) honor every particularity, even those that do not fit the regularities 
imposed by the organizational rules; ii) honor accomodation, i.e., the "ad hoc elaboration of 
rules in use" and iii) honor change, which is a intrinsic and unavoidable feature of real world 
system. 

4 We will certainly not try to prove this assumption, as we could never get over the causality 
fallacy that such a prove would entail (post hoc, p ropter hoc). A similar argument, far from 
being a mere provocation, was also put forward by [Bryant (2003). 

5 Moreover, Ivan Mich was among the first thinkers to denote a similar phenomenon as 
"principle of (paradoxically) counterproductivity": once most practices are institutionalized 
and engineered, they backfire on some of the stakeholders. 
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term "design" for brevity's sake. Other authors hav e cautioned about the fic- 
tional and ritualistic nature of this activity (e.g. Robev and Markusl 1984 ; 



Robinson and Bannon , 1991 ; Nandhakumar and AvisonT 1999 ) . We contest the 



myths in which this ritual is considered nece ssary (as also maintained within 



the CSCW, e.g. IShipman and Marshall!. I19991K given for granted and therefore 



substantially unquestionable (see also Blackwell and Green . 2008h . Conversely, 
we will argue in favor of alternative myths according to which all the layers 
pertaining to human-computer interaction in the broadest sense, - what is of- 
ten denoted as the trimurti of the Model, the Control and the View - can be 
realized by composition of elementary components without any rational design, 
and be put to work by end users alone, eventually (but not necessarily) flanked 
by IT professionals that are explicitly called to play the role of catalysts of a "re- 
action" that is substantially under no control, since it pertains to the dynamics 
of complex (socio-technical) systems. 

In this lies the reason why we also speak of a mythology, as we are aware that 
also our argumentation encompasses some myths, the most notable of which is 
that of the "end user that can develop her own artifacts" somehow. Moreover, 
this new "mythology" we are after is not "original" in any strong sense; rather 
it can be brought into focus where three different but complementary recent 
discourses meet, and seen as the outcome of a bricolage made of some indi- 
cations and suggestions coming from the three strands we will outline in the 
following sections. This presentation of ideas is done towards the foundation of 
an alternative way to build socially embedded systems. This chapter regards 
this alternative way. 

The rest of chapter will be articulated as follows: in Section[2j we will address 
the given-for-grantedness and indisputability of conceptual design in system de- 
velopment by recalling its roots in recent history. In the next three sections 
(i.e., Section [31 3] and O we will briefly gather suggestions from three distinct 
discourses on which to ground our different mythology: complexity thinking 
(in Section [3]) will invite us to distrust any formal model of social practices 
for their intrinsic opacity with respect to emerging phenomena and their unex- 
pected evolution, and distrust design-based methods for system development for 
their role in conceiving the requirement of flexibi l ity m ainly (if not totally) in 
terms of exception handling (jCabitza and Simone , 2013). Performativity think- 
ing (see Section |4j will help us reappraise the value for IT development of the 
karstic river that connects many influential thinkers from Nietzsche to Suchman, 
and will provide us the conceptual space to think system development differ- 
ently from a design-driven process. Lastly, the metaphor of the bricoleur (see 
Section [SJ, i.e., who performs the activity of bricolage, will suggest us a new 
strategy for building computer-based support in the wild. This pathway will 
lead us toward an alternative proposal, that we will articulate in Section [7] and 
discuss to some extent in Section [SJ Section |H] will end the contribution with a 
quick look at a research agenda coherent with this alternative mythology for IT 
system development. 
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2 For a genealogy of the idea of Design 



Good design is good business. 
(Thomas Watson, Jr., 19710) 

An alternative mythology of system development can be "constructed" only 
downstream of a process of deconstruction of the design-based development; 
this process would be aimed at identifying the ideas that in such a mythol- 
ogy are taken from granted; recognizing if any of these ideas are in a vibrant 
relationship with other often opposite ones (hence the idea of opposition); try- 
ing to understand where those ideas come from and how those oppositions 
got consolidated over time and are currently used in the social construction 
of meaning and v alues. Beath a nd Orlikowskil (| 1994T) began following this kind 
of approach, after iDerridal (]198l[ ) to unravel some of the incompatible assump- 
tions about the role of designers and users during development. We advocate 
that further similar initiatives could be undertaken, for instance to make sense 
of ofte n-cited oppositions like tho se between performa tive vs. ostensiv e mod- 
elling ( Poltrock and Handel , 2009), pl an vs. planning ( Suchman . 20061). devel- 
opme nt vs. growing (jTruex et a 1, 1999), global vs. local (Rollan d and Monteirol 
2002) and the two related design vs. use and designer vs. user (|Bowersl fl99lh 
ones. We believe these deconstructive analyses could be useful, for instance, to 
understand if there is something in the rethorics of the proposals that stem from 
the communities that are closer to the EUSSET forum (i.e., HCI, CSCW, PD, 
etc.) that undermines their potential to really mitigate the risk of failure in IT 
projects, as they would not aim to "overturn" the above mentioned oppositions, 
nor merge an d surpass them , but rather to recognize them being in a continu- 
ous interplay (jDerridal Il98ll ) that both asserts their irreversible difference, and 
their necessity to produce sense in our fields. 

For brevity's sake our contribution will pretend to come after that such an 
undertaking has been attempted to shed light on the surreptitious hierarchy that 
acts in the design-use opposition, and that we could try to find some new way to 
look at this dyad. In particular, we will pretend that such a deconstruction has 
shown that "the design of a thing" governs (i.e., affects, conditions) its use, and 
that such an activity, which regards the creation of new things, is considered 
sort of intellectually superior, or just deserving more interest, than the latter, 
i.e. the mere and opportunistic use of what has been produced to this ai nfl 



6 Excerpt from a talk given at the Wharton School of Business. 

7 We are aware that this point could be as easily as harshly objected with respect to IT 
system design, at least within the fields that are closer to the EUSSET community. But 
if things were actually different, why the undeniable user-related orientations of approaches 
like the user-centered design, interaction design, contextual design, participatory /cooperative 
design, seem only to affect "design" in terms of attributive specifications without ever chal- 
lenging the common concept of design? Is this linguistic phenomenon one of the "semantic 
pathol ogies" or "fr a me co nflicts" (cf. Reddy) that also recently have been mentioned in CSCW 
when [Christensen (2012) recognized their potential for subtly harmful bias in IT-related dis- 
courses? In that case we could probably trace back this phenomenon to a specific case of 
the so called "Sapir-Whorf hypothesis", i.e., the conjecture according to which linguistic cate- 
gories and usage do influence thought and attitudes in complex ways. Obviously we leave the 
questions mentioned above open to discussion by all means. 
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Granted this preliminary insight for the sake of argument, in what follows 
we will tell a story towards a possible "genealogy" of the tension between design 
and use, in which we will recall that this dyad is not a timeless construct, but 
rather it emerged out of contingent turns of history, not as the outcome of 
rationally inevitable trends or part of any grand scheme of progressive history, 
but rather at the point in history where complex, mundane, i.e., social, cultural 
and economic, and not necessarily glorious conditions got entangled^. 



2.1 A little tale of design-as-we-know-it 

This story begins in the 1950s@ when a bold idea of design, which was purporting 
itself as solution for a very wide class of problems, met a very specific demand 
for an effective solutio n that was fed by the emergence of the so retrospectively 
called "software crisis' ' dHaigbl [2O10h . This crisis can be related to two related 



phenomena: first, private companies that were customers of mainframe-based 
information systems were continually running out of memory of their storage 
systems: they continuously needed to process more and more data over time 
and for this reason they were slowly but inexorably moving from punched card- 
and sequential access tape-based storage systems to much more efficient ran- 
dom access storage systems; this caused these companies to shift from having 
small teams of in house programmers writing very specific code for their par- 
ticular needs (usually in Assembly) to buying new and more powerful hardware 
& software bundles; in this move hardware systems were typically very little 
compatible with preexisting legacy systems, while software was getting increas- 
ingly more and more difficult to write (and usually in Cobol) and maintain for 
the corresponding low level intricacies that the nascent relational model was 
introducing for the more efficient management of random access storage. Sec- 
ond, mainframe vendors were experiencing as many difficulties, in coping with 



"Here suffice to say that ancient engineers involved in the building of impressive civil fa- 
cilities, stately buildings and reliable ships, did not feel the need to have a term indicating 
the full specification - i.e., the de-sign (attested since the 16th century) - of a future accom- 
plishment - i.e., the project (attested since the 15th century). No specific term indicating 
the concept of design can be found in the whole multi- volume work De Architectura ("On 
Architecture"), authored by Vitruvius, a Roman architect and engineer and one of the most 
theoretical writers of his times, who rather used the terms 'species dispositionis', 'descriptio' 
or 'compositio' (made by 'cogitatio' and 'inventio') with different meanings. This is not a 
merely nominalistic point: what modern architect would not consider 'design' as part and 
parcel of Architecture as a general topic? Conversely, Vitruvius wrote: "Partes ipsius ar- 
chitecturae sunt tres : aedificatio, gnomonice, machinatio"; that is: architecture consists of 
three components: construction, scheduling and machine deployment. Here we can see how 
what the modern stance sees as the realization of the representation of an intellectual and 
creative achievement is dis-articulated in a connotation of design that relates it more to the 
enablement and enactment of the coordinative tasks that different practitioners involved in the 
construction articulate ; something that resonates w ith the ethnographic work of architectural 
practices described by Schmidt and Wagner (2004). 

9 The following, very short and partial indeed, account is based on the in formative and 
insightful histori o graphical studies done by Campbell-kelly and Aspraj] i2004h and, more re- 
cently, bv lHaighl d2002l. l20ld . l201lh . We also consulted the videos published by IBM Corpo- 
ration for its 100th anniversary on its page on Youtube (www.youtube.com/user/IBM). 
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an ever increasing complexity of their storage and processing systems and of 
the closely related commercial offers, in face of at least three main factors: cus- 
tomer intrinsic heterogeneity, market competition, and what epitomizes both, 
i.e., continuous changd 10 !. 

The particular idea of design that could be met in these hard times for the 
information storing and processing industry was spontaneously emerging from 
the second half of the 1950s (cf. the foundation of the SHARE association^!, 
still existing) and got a first historical legitimization within the cultural milieu 
where researchers gathered at the first two U K conferenc es on design methods 
in 1962 and 1965. As reconstructed by Lovd (Appendix l[2007), in those intel- 
lectual ambits, design was asserted as "the use of scientific principles, technical 
information and imagination in the definition of a mechanical structure, machine 
or system to perform p re-specified functions with the maximum economy and 
efficiency" ( Ederl . ll966l). and as the activity whose "effect is to initiate change in 
man made things'M | Jones , 1970l) : these are all d efinitions that resonate with the 
irresistible ontology elaborated bv lSimonl (|198l[ ). in which an "artificial world" is 
given to the Promethean attitude of system designers to be recreated and man- 
aged by these latter mainly through their rational activity of problem solving 
and scientific planning. 

When such an idea met the elusive (and then just nascent) world of software 
abstract architectures (abstract with respect to all possible situated implementa- 
tions) and abstract data models (abstract with respect to any situated nuance 
and ambiguity that business concepts could still preserve)- during the great 
endeavour of IBM to build the full compatible system, the System/360 - con- 
ceptual desi gn became b oth (part of) the solution to cope with the increasing 
complexity ( NobleL 1979h . and part of w hat cou l d be d elivered (and sold) to cus 



tomer s all together with the "big iron' ' (|Haighl . I20Q2IH As reported by lHaighl 



(|2011r ). the conviction that "to be effective, information systems must be de- 
signed - engineered if you prefer" (p. 27) justified the transformation from "a 
tightly knit family of 'computer people' into a diverse and highly fragmented 
collection of pro grammer/coders, systems analysts, and information technol- 
ogy specialists" (jEnsmengerl . 120011 ). the concurrent "elevation of syste ms men 
[or d esigners] over both accountants and data-pro cessing technicians " (jHaighl . 
201 lh and the shift from the art of programming ( Ensmenger , 2001 ) to a set 
of methodological devices, whose gist (irrespective of the extent the flow of ac- 
tivities is pipelined, looped, spiralled, and the like) is "rational" (or better yet, 
reductionistic) phasing, i.e., the idea that there are distinct phases, and the 
implied ideas of either predictive planning and development parcelization that 



10 We recall that one chapter of the influential book that Brooks wrote in f 975 as a summa 
of the lessons learned in the sixties (cf. "The mythical man-month: essays on software") was 
aptly entitled "Plan the system for change" (our emphasis). 

1 1 http : / / www. share .org 

12 It is also noteworthy that the so called "hardware", in those same years, was looking 
more and more like cold "black boxes", due to the coeval microelectronics revolution that was 
irreversibly substituting the large amount of hand-crafted wiring and "tangible" logic of a 
computer with new and inscrutable integrated circuits. 
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phase thinking made possiblj^l. 

In virtue of this "new" (or just renovated) labor force, as soon as the need 
emerged to really embed a computational system within an organization (and 
not only put it in one of its facilities as mere punched card and magnetic tape 
equipment), design and analysis left the realm of the builders of hard ware to 



be pr ojected in the realm of the commercial and consulting services (|Haighl . 
1 2 1 lh that were oriented to isolate the customer's needs, understand how to 
satisfy therrF^l, and understand how to deploy more and more sophisticated 
applications in their settings to integrate those systems with their organizational 
procedure^. 

It is while analysis and design became part and parcel of a deliverab le com 



modity that had to be attuned to the strategic goals of the customer (jHaighl . 

that these activities took the prominently representational and visual 
flavour they have still toda\P^I. since, in so doing, they could also more faithfully 
mirror the conceptual ideas (cf. the Vitruvian coqitatio) they r eified. As both 



a commodity task and a social ritual ( Robev and Mark us. 1984), design consol- 



idated itself as the phase in which to generate representations that could duly 
and precisely specify the system (that is the root meaning of the word de-sign) 
and shed light (that is the root meaning of project) on the future activities 
of factual realization of the system, while at the same time also "displaying" 
the necessary expertise needed in both these activities. In such a ritual, visual 
languages, specification formalisms, both diagrammatic and textual representa- 
tions that characterize current design have since then played a role in creating 
and maintaining the divide between "wh o can read" and "who can't", between 
the hired pundit and the ordinary user (|lllichl . Il977l ). In so doing, the divide 



between these two ro les came to its current ratificatio n; the practice of design 
became a sort of play ( Nandhakumar and Avison . 1999h where ostentation of ex- 



pertise both justified and legitimized the economic exchange going on between 
the pundit/supplier and the customer, i.e., between who designs and who buys 
the outcome of design, also in light of the fact that this explicit and represen- 
tationally paraded expertise was often "bounced off", so that the programs of 



13 This parcelization is nowadays so obvious that offshore outsourcing has become a practice 
that is conceptually legitimate even before than technologically feasible. 

14 As Brooks noticed "a programmer delivers satisfaction of a user need rather than any 
tangible product". Yet Cosgrove, already in 1971, recognized that "both the actual need and 
the user's perception of [its] needs will change as programs are built, tested, and used". 

15 To this respect, we deem the quotation mentioned at the beginning of this section by the 
President of IBM relevant and indicative of those commercial strategies, beyond the conven- 
tional (and perhaps not so true) connotation of that sentence by which good design "naturally" 
leads to good systems, and these latter to good sales. 

16 We recall the definition of software given by Bauer in 1965: " systems analysis and design, 
programming and computer-based services, accomplished by users, computer manufacturers 
and others." (our emphasis), or the definition given by Head in 1968 " the entire process of 
systems analysis and design, programming, testing and implementation, as well as th e docu- 
ment ation that accompanies this process." (our emphasis). All citations taken from jHaigh, 
12002ft . 

From (Haigh, 2010): "the systems men of the 1950s had also paid attention to flowcharting 
and analysis, having invented many of the charting techniques modified by the new generation 
of software engineering gurus". 



digitization could act as symbols of an organization's rationality and reliability, 
both for the inside and the outside. 

From this very succinct account, the wrongest conclusion to draw would be 
that before the 1960s people did not design computational systems, even very 
complicated ones. Yet, we argue that befor e that partic ular period of time, 



when the word "software" did not even exist (jHaighl I2002Q . the concept of de- 
sign was a semantic bipole, so to say, vibrating in a state of balance: on the 
one hand, one would detect a representational pole, from which design is seen 
as the conception of "clear and distinct" representations of what a system (i.e., 
an orderly something made of parts) is (i.e., its structure) and of what it does 
(i.e., its behavior); on the other hand, a performative stance, from where design 
is related to a collaborative process of construction where material representa- 
tions are used for the sake of reaching a mutual understanding and stipulating 
a tangible agreement of what is to be built and how. Every time some material 
arrangement must be done, design will also come with both these flavour^. 
Yet when software architectures and high-level behaviors of a computationa l 



system are at stake, representations and their generative power ( Bowersl 1992f) 



get the upper hand. For instance, it is true that a UML Collaboration Diagram 
makes an idea of interaction between (more or less abstract) components explicit, 
and hence something that could be colla boratively discussed both within and 
across communities of practitioners (e.g., McLeod and Doolin , 2010): this is its 



descriptive role; but such a diagram is also intended to formally specify the (ab- 
stract) structure and behavior of a computational machine whose components 
are supposed to interact as design-ated: in being a formalism, such a design ob- 
ject is able to gene rate other "rep resentations through the operation of rules over 
some vocabulary' ' (|Bowersl[l99l and to prescribe things. When this generative 



power is trans-lated again in the arena of human collaboration, a series of small 
and sometimes imp erceptible (but not for this rea son more harmless) ontological 



drifts described bv lRobinson and Bannon (1991) occur, and among those drifts 



the most dangerous one occurs w hen the prescriptive power of models, their be- 
ing ostensive in the denotation of iPoltrock and Handel ( 20091) . is confused with 



their descriptive power, i.e., their performative nature (jPoltrock and Handel 



2009). 



Since this tension has received a lot of consideration within the CSCW 
community, it is not necessary to linger over it any longer. 

In summary, the idea of design we have outlined above got crescent legit- 



18 Indeed, if one is to look carefully at the world of machines, things would look to be much 
more performative than representational, even if we tend to think that a representation of 
intended action, i.e., the algorithm within a structured procedural program, really informs 
and affects its execution (the machine's behavior). Indeed, we here recall that it was in fact 
the wind and the water that made the mill within the Benedictine monastery to mill (cf. the 
marvellous account by Mumford contained in The Myth of the Machine, 1967), not the plan 
that described the articulation of its parts (if any) , much in the same way that it is electrical 
power that makes electronic artifacts act (if we agree that no such a thing like a ghost in 
the machine exists), in virtue of an orderly articulation of a pattern of solids and voids, of 
present and absent magnetic fields, of "positive and negative spaces" (like the cogs and slots 
in the cogwheels of a mill machine, like the holes of a paper punched card) that in history 
have progressively become softer and softer. 
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imization and strength within an engineering response to the software crisis that 
broke software development into phases denoted with terms such as 'analysis', 
'design', 'implementation', 'testing', and so forth, and that also brought forth 
the idea that such activities could be performed in a circumscribed and orderly 
way (not to mention the idea that these could be controlled in a strict sequential 
fashion, as it happens in other "hard" engineering fields, like civil and aeronau- 
tics engineering). Till nowadays, all current software development methodolo- 
gies are imbued with the idea of method, that is of orderly "path" between the 
"idea" of something and its realization, i.e., the separation and distinction (that 
is ontological, temporal and causal) between the "design" of a thing and the 
designed thing; between the plan of doing something (and its representation, 
of course) and the "real" thing. Differently from other concepts borrowed from 
"hard engineering" that were almost immediately denoted as naive and inad- 
equate with regard to software (e.g., the notorious waterfall model), the idea 
of phasing, hence the opposition design-use, has become pervasive and it has 
been molded over time up to its current versions, i.e., the iterative, participatory 
and evolutionary methods that characterize, among others, the agile approaches 
(e.g., Scrum, XP programming). The idea (and practice!) of phasing brought 
in the dichotomy between design and subsequent phases; the idea of design, in 
its turn, brought in (with authority) the legitimacy of the practice of model- 
ing a software artifact. This contributed in digging an increasingly deeper rift 
between the category of user and the one of the designers, who have differen- 
tiated themselves from laymen also in virtue of their jargon, representational 
formalisms and modeling technicalities. 



2.2 Sketches from a different future 

Could things have gone different from how they did? Does reconstructing 
how the current idea of design got consolidated over time tell us something 
in regard to whether a different idea of it could ever stan d out in the fu- 
ture? Andrew Pickeri ng, in a series o f interesting articles ( Pickeriiigl 2004 



20081) and even a book (|Pickeringj.[2010l ). has thoroughly focused on how some 



early British s cientists and en gineers (who were happy to call themselves "cy- 
berneticians" (jPickerinei 201Ct p. 223)), and notably Gordon Pask and Stafford 



Beer, were addressing the same goal of IBM of improving the Western organi- 
zation and decision making of its management in the same years but, instead 
of leveraging representational and conceptual means, by developing a radically 
alternative approach, through the first proposals and experimentations in bio- 
logical computing and cybernetic feedback theories. Their approach, according 
to Pickering, was dispensed entirely with representation and devoted to the con- 
crete experimenting of "productive and performative relations via open-ended 
and intimate engagements": Pask and Beer, in the years in which Cobol was 
introducing the seminal concept of input and output as a first class statement, 
claimed that managers were not actually interested in getting an answer in sym- 
bolic and digital format (that is in outputs), but rather in using the answer, 
that is in making sense of the state of affairs in any form this could come to 
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their attention 19 !. 

This research program was not pursued for an intrinsic eccentricity of isolated 
researcher^, but rather as consequence of the profound realization that "in a 
world of exceedingly complex systems, for which any representation can only be 
provisional, performance is what we need to care about. The important thing is 
that the firm adapts to its ever-c hanging environm ent, not that we find the right 
representation of either entity" (Pickering, 2010l p. 235). It is the realization 
that "the world is populated by a multiplicity of interacting exceedingly complex 
systems" that urges us to be fascinated by alternative mythologies other than 
the representational, symbolic one sponsored by IBM exactly fifty years ago. 



3 It's a complex (brave new) world 

The captain may, by simply moving an electrical switch, instantly close the 
doors throughout and make the vessel practically unsinkablj^l, [Olympic and 
Titanic] are designed to be unsinkabld 2 " 2 ! 

In the first decades of the 21st century many disciplines in the human, social 
and organizational studies have discovered complexity. In finding (or acknowl- 
edging) their realm of interest being complex, in some cases, authors from those 
traditions have promoted a debate in their com munities about the very foun- 
dations of their practices and methods (see e.g., iGreenhalgh et al 2010); more 



often, elements or suggestions from complexity theory are included in more or 
less traditional fram eworks to reinforce their ramparts against the g a les of un- 
predictability (e.g., Norman and Kurasl 12004 . IPavard and Dugdal d l2006h : in 



these sallies in the world of complexity, authors usually proceed by recalling the 
definition of complex system that they deem more informative for their aims and 
pick up some of the properties that such systems exhibit to concentrate on how 
those could impact on their fields of research: in this jumble of definitions and 
claims, the casual reader could get confused, also for the fact that complexity 



19 Just to make this point more clear, we recall that their first experiments to this regard 
regarded the responses of pond ecosystems to environmental stimuli as alternative information 
processing systems than electronic mainframes! 

20 One could object that the cybernetic, embodied, biological approach of the early cyberneti- 
cians that Pickering speaks about just did not stand the test of time, while the representational 
stance has brought to us incredibly fast and reliable logistics management as well as pervasive 
systems for the provision of goods and services worldwide. As a matter of fact, no one can 
really guess how the viable system model developed by Beer would have changed the Western 
firm (or how) with its biological and systemic metaphors and holistic interventions. Little help 
to this respect can come from post-mortem analyses of the Cybersyn Project, which tried to 
build a comprehensive decision support system for the governance of Chile economy during 
the government of President Salvador Allende (1971-1973), as any interpretation of the most 
controversial aspects of that socio-economic experiment could be easily made an instrument of 
political propaganda. Rather, we refer again to the contributions mentioned at the beginning 
of Section [T] arguing about the alleged successes of modern IT production methodolog ies, as 
well o f the actual impact of these systems on general productivity and affluence (see also Carr, 
12004) ). 

21 Shipbuilder, Special Edition, 1911 
22 White Star promotional flyer, 1912 
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seems to be the carrefour where hard science and softer ones, and within these 
latter where pragmatist / culturalist and rationalist / functi onalist approaches, all 



meet and blend together crea tively if not promiscuously ([Kaghan and Bowker 
20011: iKim and Kaplan! 20060 



More specifically, in the IT system development discourse the usual line of ar- 
gumentation is: the social and the technical components constituting an organi- 
zational 'overvalP system are highly inter-dependent (this leading to the concept 
of socio-technical systems by the the Tavistock School); these systems encom- 
pass many components, of different types, which a re linked in various ways , 



whos e patterns can change unexpectedly and often (pchneberger and McLean , 



2003); hence they are complex systems, hence "our knowledge and understand 



ing of how different components work and int eract, and accordingly how the 



system as a whole work, will be incomplete" (jHanseth and Ciborral 120071 p. 
5), hence "the more complex a system is, the more incomplete our knowledge 
will be, and the more unintended effects our interventions will produce.". We 
substantially subscribe this line of thought, which is found ed on the catchy idea 



that "where there are strong interactions among elements" ([Axelrod and Cohen 



1999), there you find a complex system (made of those elements, of course); yet 



we also think a word of caution is necessary. 

We recognize that the simplest way to see complexity is to take it as an 
explanatory concept, that is to acknowledge that it is invoked or referred to "to 
proffer a form of explanation" (jPalev and Eval . 1201 lh for a situation, a pattern 



of behavior that it is thought to derive (the right term here would be "emerge") 
in non-linear and almost unpredictable ways from a multitude of interacting 
agents. Yet, for complexity to explain something, one has also to assume that 
the agents involved follow, or can be interpreted as following, relatively simple 
ruleq^j|. If we retain this as the main principle underlying complex systems, and 
how the "theory" conceive of them, then we should also agree with those au- 
thors who claim that most of the recent contributions coming from the human 
studies (including the organizational domain) often end up by producing refer- 
ences to complexity theory that are not dissimilar from "mere retellings of old 
tales, [which use] complexity terminol ogy tacked on retrospectively, g ratuitously 



and, i n many cases , quite awkwardly" (jMaguire and McKelvevl . 119991 ): more pre- 
cisely, |Palevl(l2007h makes the point that many researches that declare a focus in 



complex systems do actually refer to the open systems thinking, which between 
the 1960s and the 80s was aimed at replacing the Tayloristic organisation-as- 
machine metaphor with the metaphor of organisation-as-organism. 

For this reason, we prefer to take a pragmatic stance and refrain from rely- 
ing too much on complexity as an explanatory term; rather in what follows we 



23 For this reason, trying to make even a brief account for the vast plethora of contributions 
that introduce complexity-related in IT syst em design would be o ut of scope. 

24 This point deserves to continue quoting Paley and Eva (2011): "however, a complex sys- 
tem is an abstraction, and so are [its generative] 'rules' of behaviour. In all non-computer cases, 
the 'rule' as a semantic expression is an inference, partly inductive and partly hypothetico- 
deductive. Inductively, it is inferred from the inveterate behaviour of individuals; at the same 
time, it functions as a hypothesis tested by its ability, in combination with the other rules in 
the set, to produce or predict the global patterns of the complex system" 
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adopt it as a descriptive term, to account for post-hoc analyses. As even Simon 
acknowledged in 1968: "the main route to the development and impro vement 
of tim e-sharing systems was to build them and see how they behaved" (jSimonl . 
198l[ p. 20). These systems turned out to be exceedingly complex systems, that 
is systems that, to be understood, "had to be constructed, and their behavior ob- 
served" (ibidem) . Therefore we like to start the line of argumentation mentioned 
above from the end, that is from the realization that our knowledge of how a com- 
plex (socio-technical) system will behave is necessarily incomplete (if not wrong 
to some extent) and that "unintended consequences" (either positive or nega- 
tive) are unavoidable and certain irrespective of the unremitting diligentness we 
put in analysing and planning how a specific system (encompassing people and 
things) "behaves". Indeed, an increasing number of researchers, in th e line of 
that strand o f research that focuses on unintended consequences (e.g., iMerton . 
119361: iTennerl . Il997t lAsh et all 12004 have recentl y come to speaking of "law of 
unintended consequences" (e.g., iMansfield . l2010h and agree that the only way 
to genuinely eliminate risks of (socio-tec hnical) complex systems is to follow 
the recommendation "do not build them!" ( Hanseth and Ciborra . 2007 . p. lof^l. 
We continuously observe that any claim to know how a technology-in-practice 
will impact on the setting in which it is embedded, that is, to know in advance 
that a system that was specifically designed for enabling a set of functions, sup- 
porting a set of tasks and fulfilling a set of needs will actually re ach the goals 
established at design time, is frustrated by evidence and history ( Jonesl . 19961 : 
Rochlinl . [l998h . 



In complex systems change must be expected: this has been an inductively 
supported common place in system design since its foundation, and we can re- 
lated it to the vast research undergone about exception handling in software 
engineering so far; yet the effect of change must be also recognized as intrinsi- 
cally unpredictable, an d we believe that this insight comes to be less recognized 
than it should. Thus, IMansfield (|2010l p. 25) argues that 'if the majority of 
computer-based socio-technical systems fail to meet the expectations of their 
sponsors, perhaps that is due to their architecture"; consequently he submits 
design-oriented principles that call for the employment of small components 
that are mutually loosely coupled, so as to avoid that the break down of one of 
those could propagate to the others in complex ways (cf. the butterfly effect); 
and the adoption of a layered architecture where some layers are allowed to 
change (and adapt to changes, or evolve in response to them) at different rates 
to account for the varying rate of impact of the events affecting them. 

In addition to these recommendations, we perceive the undert aking of de- 
signin g "to meet specified expectations" to be a "wicked problem" (jFitzpatrick . 
2003), i.e., something for which there is no definitive formulation, no stopping 
rule, and such that any attempt to treat it as it were not a wicked problem 
would only worsen thingj^l. For this reason, we submit that the simpler recipe 



25 This resonates with both the half-serious epigram of the "Murphy's Law" and with the 
full-serious theory of Normal Accident by Charles Perrow. 

26 To this respect, then, rather than speaking of complex systems, and their fuzzy definition, 
we like to mention the taxonomy proposed by Ackoff, according to which there are three types 
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to mitigate the opportunity of failure is to change both the architecture and 
the method, or better yet, the attitude: therefore, to abandon any method that 
deals with the future, that projects an idea of future in the realization of the 
tool that is supposed to reach it, and embrace the possibility that the com- 
ponents of the socio-technical system would adapt and co-evolve in ways that 
no designer would imagine, not necessa rily for the worse. On a prac tical side, 
this would mean to "follow the actors" ( Bannon , 1992 ; Latour , 19961) . but also 
to turn to their traditional artifacts, not o nly as sources of inspiration but also 
as ground upon which to build new tools (jCabitzal 120111) and, above all, to let 
actors support themselves. 

Thus, the discourse on complexity turned out to become (or unveil) a dis- 
course on unpredictability (cf. the iceberg struck by the Titanic); and this, 
in its turn, leads us to the seemingly dullest of the design principles, the one 
expressed in the French phrase laissez-faire, literally "let [them] do". Although 
this recommendation could look shallow, in the next three sections we will see 
what "letting do" means (and why it is important), who must be let do (i.e., end 
users) , and how system development should be oriented towards the building of 
an environment to build systems that is specifically designed to allow for doing 
without design and to allow for unexpected things to just happen. 



4 The rediscovery of performativity 

Many things difficult to design prove easy to performance. 
(Samuel Johnson, 175^3) 

In this section we will first consider what we mean when we advocate that 
the alternative mythology for IT system development we are envisioning should 
make a "performative turn". This expression is getting more and more impor- 
tance in fields that have historically had always an influence on design-oriented 
discourse. Then, we will consider how the performative discourse has already 
come into design-related mythologies, in order to highlight the specific strand 
we aim to renovate for our proposal. 

of system: messes, problems and puzzles. A mess is a complex arrangement that defies 
attempts to define it precisely; a problem, conversely, does have a specific structure that can 
be specified at some level of detail, but not necessarily any single, clear-cut solution; the 
puzzle is a well-defined and well-structured problem with a specific solution. Accounts from 
the shop floor and the field of work show that "when embarking on the creation of a large 
socio-technical system, many sponsors believe they have a problem, when they actually have 
a mess, whil e engineers believ e they have a puzzle when, if they are lucky, they actually have 
a problem" (Mansfield, 20icj, p. 118). In the same vein, Pidd concluded that "the greatest 
mistake that can be made when dealing with a mess is to carve off part of the mess, treat it 
as a problem and then solve it as a puzzle - ignoring its links with other aspects of the mess." 
(ibidem). 

27 Line pronounced by Imlac within the apologue 'Rasselas'. 
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4.1 The performative turn 

The expression "performative turn" is usually used to indicate two strictly re- 
lated things that we nevertheless prefer to distinguish for clarity's sake. On 
the one hand, it indicates a historically circumscribed research program, which 
has received an increasing interest in the last fifteen years by researchers in- 
volved in cultural and social studies, like the Science and Technology Studies 
field (notably Pickering, Latour) and related disciplines like ethnology, anthro- 
pology, sociology and linguistics; in this former case, the term "turn" indicates 
the aim of this research endeavour to investigate an alternative way to look at 
how people interact, work and share knowledge in social settings with respect 
to more mainstream strands like the pragmatic and realist paradigms, endors- 
ing the claim that people creat e and recre a te me aning and knowledge in social 
settings through performance (|Van Housd . 120091). and that even social reality 



itself is "created" while people "do things". As Law and Singleton (2003) put it 
down: 

The differences between realism and pragmatism are important, but neither 
share the performative assumption that reality is brought into being in the pro- 
cess of knowing. Or, to put it more precisely, neither would assume that the 
object that is known and the subject that does the knowing are co-produced in 
the same performance, that the epistemological problem (what is true) and the 
ontological question (what is) are both resolved (or not) in the same moment. 

This alternative approach shared the critique towards systemic, fully-specified 
and rationally-conceived abstractions(e.g., with the non-representational the- 
oristfQ) and drew on the metaphor^ of "performance" to reflect "a growing 
discontent with the traditional social sciences and their understanding of prac- 
tices as texts or representations of genuinely symbolic concepts", to express "the 
reversion from systems of representations to processes of practice and perfor- 
mance", and to f ocus on "the active social constru ction of reality rather than its 
representation" (jDirksmeier and Helbrechtllioosh . 



In an attempt to summarize t he recent, and quite pr otean, discourse about 



q uite pr 

performativity in two lines, after iBramming et al (|2012 ) we highlight three in- 



tertwined aspects: i) reality is understood as incessant creation or practice; ii) 
matter itself, is understood as "A"entangled intra-relation"; and, of course, iii) 
individuals do not pre-exist their interactions in any essentialist, objectivistic 
sense. 

Yet this recent research line can be said to be grounded in a more general 
idea of performativity. It is this second connotation of the expression "per- 
formative turn" that we refer to in our proposal. This latter, rather than a 
specific research program, can be better characterized as a sort of "sensitivity 



28 It should be noted though that "a performative perspective does not delete the ide a of 
representation, but rather views it as a specific aspect of performativity" (Jensen, 2005), in 
that it focuses on the activity of representing, planning, modeling rather than on the material 
outcome of those practices. 

29 Here and elsewhere we use the term metaphor in the Nietzschean sense, as something that 
is used to impose order and intelligibility on a world that we cannot access directly. 
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to specificities of materially heterogeneous eve nts with specia l reference to dif- 



ferences and relations between performances" ( Jensen . 2003). This sensitivity 
has followed in the last century or so a peculiar karstic trend: it has recurred a 
number of times by different authors of different cultural milieus and, although 
each time it was capable to gain a strong interest, this was never sufficient to 
establish itself as the mainstream thought in any of those milieus, and somehow 
submerged until a next thinker contributed in its reappraisal. 

In this sense, therefore, the idea of a "performative turn" evokes a more a- 
historical attitude, which was exhibited by individuals that have deliberatively 
turned away their focus from the allures of representationalism to embrace a 
more action-oriented and embodied perspective. The term "turn" thus indicates 
the will to reverse the ontological premises that the world is populated with 
particular objects, entities, configurations that exist i n and of them selves and 
that are endowed with particular essential qualities ( Jensen . 20021 p. 67) to 



consider objects, "not singular entities, but rather textures of partially coher- 
ent and partially co-ordinated performances" existing through multiple situated 
practices. 

This sensitivity, or will, or discontent with representational/conceptual tenets 
indicates a sort of "fil rouge" that binds together thinkers like Nietzsch e, Hei 



degge r, Derrida, Pickering, Latoui|fj and some relevant feminist theorists (|Bathl . 
2009) like Judith Butler, Karen Barad and, especially for her involvement in the 
IT debate, Lucy Suchman (just to mention a few of those authors that influ- 
enced our understanding of the performative approach) . A common trait among 
these thinkers seems then the need to find a viable alternative to representation- 
alistic tenets (i.e., stances that could be called as Cartesian , Kantian or simply 
'modernlf]] in some philosophy circles(cf., e.g., Rortv . 199lh ). to shift the focus 



from questions of correspondence betw een models /r epresentations and reality, 
to matters of practices/doings/actions (jBarad . 2003 ). 



In short, a performative approach asks us as observers of social settings to 
abandon the idea that these are sets of "object that are", to embrace the idea 
they are made of "events that do". In doing so, it gives us a "resource to counter 
the positivist stance which essentializes categories and naturalizes the qualities 
of the entities whose stable e xistence it posits" (e.g., gender as a fixed attribute 
of a person) ( Licoppe , 2010l ). The concept of performativity therefore invites 



us to abandon the Kantian notion of "thing per se" (at least in system design) 
to recognize the relational and manifold nature of any perceived phenomenon, 



30 It is typical of fil rouge to binds together unsuspected associates, like Pickering and La- 
tour, for instance. One thing that unites these thinkers, e.g., is that they are both "happy 
enough" to spe ak of material a gency in nature without imputing any intentionality to the 
word "agency" llPickerin gj, Il99 5|. p. 6 ). 

31 Yet, we agree with[jensen (20020 when he points out that "the performative turn is a way 
to refuse the choice between the modern and the post-modern. The modern is about order 
and purity. The post modern is a celebration of fragments and disorder. The performative 
turn is a series of claims and sensitivities that try to reach a fractional space in between. 
Something that is beyond the mono-dimensionality of modernity and beyond the free-floating 
multi-dimensionality of the post-modern. In this sense it has much in common with the parts 
of the ANT-tradition that claim to be non-modern." 
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irrespective of its seeming soliditjjfj, as well as the co- constitutive entanglement 
of the social and the technological (i.e. material), and " the performance of 
the emergent sociomaterial assemblage" (jOrlikowskil . 120071) . According to this 
perspective, "meaning" is thus seen as an emergent phenomenon (or an epiphe- 
nomenon) of interaction but, even beyond this point, as a transient 

aspect of embodied in teraction (iDourishl . 200 ll ) that cannot be really decoupled 
from situated action ( Suchmanl . 120061 ) nor caught in abstract terms. 

In this vein, researchers adopting a performative turn put first in their re- 
search agenda the study of the contingencies of time, space, technology, materi- 
ality or discourse, " the heterogeneou s sociomateriality and real-time contingency 
of performance", as lSuchman ( 20061) calls them (p. xii), all things that the more 
classical "repres entational " mod el of thinking that is typical of "20th century 
technoscience" (ISuchmanl . \2004 . i.e., the one assuming a detached observer 
that studies real objects and their essential properties in an objective world (or 
that designs and puts new objects into the world), escapes either consciously 
or unaware with profound consequences als o on the concept ion of the role of 
technology in society, and of its "designers" (jOrlikowskil 120071 ) . 



4.2 The performativity fil rouge 

In order to frame how the concept of performativity can influence IT system de- 
sign in practical ways, we have to briefly outline the fil rouge mentioned above, 
which binds together influential thinkers of the last 150 years with the founda- 
tions of the CSCW approach to system design. To this aim we have first to make 
a clear distinction between the discourse on performativity we are interested in, 
and the so called "performance studies". These latter are usually at stake where 
scholars and rese archers in the I T lite rature use expressions like "designing for 
perform ativity" ([M orriso n et a 3. l20inh . "the role of performance in design re- 



search" (jJacucci et all . 120051 ) or "performing design". These expressions are more 
relate d to the traditional meaning of performance ( Dirksmeier and Helbrecritl 
2008), as "showing of a doing" (cf. Grimes) or "activity before a particular set of 
observers" (cf. Goffmanr^l and they point all more or less to the "artistic" side 
of the discourse on performativity and as such they tend to "preserve", if not 
enhancing, the creative role of designers instead of contributing in the overturn 
of the necessity of the idea of design. 

Conversely, the concept of performativity we refer to is rooted in the Niet- 



32 Just to back the legitimacy of the turn requested to see action and events where main- 
stream design sees things, we here recall that our (not too far) ancestors in their language 
(i.e., Latin, Greek and Old English) used the words 'res', 'pragma ' and 'thing' (respectively) 
in order to denote both an affair, a deed, a business, or assembly (Telier, 2011, p. 1), as well 
as the matters that were discussed and deliberated in such occasions and meetings. In other 
words, in our past (probably before having become modern - cf. Latour) we could not see as 
the subject, the act and its motivation or 'cause' (cf. 'cosa' in Italian) being untwined and 
disentangled with the material matters involved in such occasions. 

33 It is nevertheless worthy of note that the meaning of performance as "performing a play", 
"playing a drama" is much later than the more general meaning of "carrying out a promise", 
or "carrying in effect something" that is from the 16th century approximately. 
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zsche's seminally deconstructive analysis of the relation between words and the 
world, and in his powerful intuition according to which looking for a specific 
"doer" behind any action is recognized as an arbitrary and unnecessary (and 
indeed confounding) aclF^l. This seminal contribution was then retaken by phe- 
nomenologist scholars, especially Heidegger, who contributed in the same mould 
by articulating further the idea that the onl y way of being of humans (i.e ., Da- 



sein) is engagement in practices (Existenz) ([Riemer and Johnston . 120121) . that 
these latter depend on equipment] for their performance, and that the relation- 
ship between this latter and Dasein is fundamentally co-constitutive ( Turned . 



200a). Many affinities ca n be then found bet ween Heidegger and J. L. Austin (see 



e.g., those discussed in Glendinnind . Il998 ). the language philosopher who in- 



troduced the concept of performative utterance to account for the capacity of 
human speech to act, i.e. have an effect in the material world, rather than 
just simply describe reality in terms of 'true' and 'false' statements. In this 
strand, Law somehow questioned the orderly taxonomy proposed by Austin 
and claimed that "all statements are in the slippery space between performative 
and constative", thus turning "the question of constative vs. performative [. . .] 
into an empiri cal question, and thus potentially an object for a sociology of 



performances" (jJensenl 120021 ) . 



Years later, approximate ly at the same time when the se concepts were taken 
up in the IT design arena bv lWinograd and Floresl ( 1986 ) in their reappraisal of 



the Austin's (and Searle's) elaboration of the so called "speech acts" , the perfor- 
mative "fil rouge" unfolded again in the works of Andrew Pickering, especially 
in those contributions where he made a clear dinstiction between a "representa- 
tional idio m" and a "perfo rmative idiom" in scientific and technology-oriented 
disco urses (Pickerin3 Il995l) . and in particular for our design-related discourse, 



when iPickerina (|2008f ) contrasts the modern technoscientific approach to the 



design of things with the approach genuinely followed by British cyberneticians, 
like Beer, Ashby and Pask, i.e., a hand-on experimental, performative and non 
representational one. At th e same time, other authors drew upon the critical 
reinterpretation by Derrida ( Simonl , 120101 ) of the Austin's original differentiation 



between performatives and constatives, most notably Judith Butler and Karen 
Barad. These latter elaborated a complex concept of (posthumanist) performa- 
tivity around the repetitive, or citational, aspects of performance, i.e., its ability 
to produce materiality. In this view, social structures, like rules and categories 
(such as gender) are not pre-existent attributes of a given object or its behav- 
ior, but rather they are continuously produced through processes of repetition 
and social legitimization. This conviction echoes, but also in some way goes 
beyond, the views animated by Wittgenstein philosophy that recognize how, 



34 We are obviously referring to the famous passage in "The Genealogy of Morals" where 
Nietzsche pointed out that "there is no 'being' behind doing, acting, becoming: 'the doer' 
is merely a fiction added to the 'doing'. Doing is all" (original: es giebt kein 'Sein' hinter 
dem Thun, Wirken, Werden; 'der Thaeter' ist zum Thun bloss hinzugedichtet, - das Thun ist 
Alles). 

35 Equipment can be seen to denote those things, or artifacts, that the Dasein encounters in 
fluent use, entangled and experienced in performance, when they are ready-to-hand (Zuhan- 
denheit) . 
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due to the intrinsic underspecification of human behaviors ([Schmidt) . 120111 ). it 
is the practice that determines the rule rather than the opposite, and that in- 
vite to abandon an "objectified and detached view of rules and procedures as 
external objects with fixed properties, to a performative view where rule follow- 
ing is ch aracterized as a t ypically emergent, distributed and artifact-mediated 
activity" (|D'Adderiol . 120081) . 



4.3 Performativity for IT system development 

All that said, one could rightly wonder what the performative turn, as it has 
been characterized above, has to do with the discourse regarding IT design in 
socio-technical settings and, above all, if there is anything new. Although some 
of the p erformativity t enets , like paying attention to "the negotiations between 
actors" ( Wagner et aj . 20101 p. 67 ) and the question of when design stops and 



use begins Ccf. e.g. lBrandlll995h " may seem old to people within the CSCW 



tradition" and related ones (i.e., HCI, PD, and the like! 36 !, we believe that this 
perspective can be fruitful along both the practical and conceptual dimension. 

4.3.1 On the practical side: towards new meaningful development 
cycles 

From the practical point of view, only a few contributions so far r efer to the per - 
formative tenets explicitly with respect to design;, for instance, Jensen ( 20081 ) 



advocates a reorientation of both the understanding and (less clearly, though) 
the practice of the process of IT design (or more specifically of CSCW design) 
along the performativity strand; to this aim, he submits recommendations to 
keep in mind performative aspects in the design process, such as that "neither 
humans nor technologies determine each other" deterministically, and that "ma- 
teriality might trick us in practice". Unfortunately, the author falls short of 
clarifying how a performativity-aware disposition, or "relativising one's own on- 
tology" (although certainly a useful exercise) could also "revitalize des ign", and 
really change the practice of IT design. With a more practical attitude, iDanholtJ 
(2005) makes an argument about the performative nature of prototypes, by im- 



plying with this expression that prototypes " affect users in concrete, material, 
bodily ways in situ". Recognizing the performative nature of prototyping is then 
related to recognizing that this way of designing artifact is "mutually transfor- 
mative for users as well as for the technology, a process of co-construction of 
humans and artifact"; if design "is considered to be performative" it is recog- 
nized as "an emergent process where the end result is not predicated by either 
users or designers, but [is] an outcome of the process. [. . . ] Performativity thus 
also means that the existing is continuously performed and reiterated in order 
to persist, which means that the existing is also always under construction and 



36 This was honestly admitted by I Jen sen (2008), who has nevertheless ad vocated a better 
consid eration of these ideas within those traditions. Yet, two years later Bratteteig et al 
||2010| . p. 31) have conversely recognized that "the performative turn in post-structuralism is 
perhaps under-articulated in design research." 
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transformation. Slight changes in the way things are done lead to novel exis- 
tences. Performativity thus imply a continuous possibility of transforming the 
existing". 

While we would fully subscribe these conclusions, we notice how user-centered, 
and even participatory design, approaches (let alone any approach within the 
more traditional, engineering mythology), in which users are considered to hold 
important knowledge on their practice and, in virtue of this competence, are 
involved in the design process (in some form), still consider end- users, as well as 
their target practice, as pre-existing the design process and somehow invariant 
to the task, in its essential traits. Thus, we agree that prototyping and partici- 
patory prototyping, especially when prototypes are not merely representational 
ones (i.e., mock-ups) b ut rather are working gears (like in the framework pre- 



sented in Hare], 20081) . can make the distance between design and use (and 



hence designers and users) shorter; but, still, if the prototype is tweaked and 
co-constructed in a controlled environment, in a design ambit, that is off-line 
with respect to the flesh and bones of (situated) action, then the performa- 
tive dimension of the development process is still kept at the margin of the real 
never- ending (and very ap tly depicted as loop-closed) process of the task-artifact 



cycle ([Carroll et all . 119911 ). where both coevolve as a whole and at a different 
pace. 

Within a performative strand, such a cycle would likely resemble a more 
intertwined figure, where there is no such a thing like the task without the 
artifact by which it is accomplished, and the artifact alone is just inert ac- 
couterment outside the task. Taking seriously that "the social organisation of 
work does not pre-exist in any precise or de tailed way, but i s cons tituted 'in the 
[artifact-mediated] doing' by practitioners" ( Buescher et aAl2001 ) suggests then 



to consider a variation of the widely known Taijitu symbol (see Figure [T]) to rep- 
resent the task-artifact co-evolution: task^l occur only when artifacts are used; 
artifacts make sense to practitioners only when these are put to work; in other 
words, there is anything but situated action, emerging from the indissoluble en- 
tanglement of tasks and artifacts. It goes without saying that entanglements 
cannot really be designed, as "the take-up, modification and rejection of tech- 
nology in a work setting, and the [conseguent] accommodation of work practices 
that take place around a developing technology, are radically unknowable and 
unpredictable" ( Buescher et all . 2001 ) till it actually occurs. 



4.3.2 On the conceptual side: back to the future 

The conceptual contribution is no less important if it's true what lSchmidt ([l999h 



once pointed out, i.e., that "Lucy Suchman's radical critique of cognitive science 
and the "situated action" perspective she proposed has played a significant role in 
defining the CSCW agenda and has become a shared frame of reference to many, 
perhaps most, of us". In the last 25 years, from the publication of "Plans and 



37 We use it the plural form, as it could be difficult, if not arbitrary, to distinguish between 
different tasks in actual, often multi-tasking practice where means, concerns and ends got 
mutually mingled. 



20 




TASK 



ART I FACT 





Figure 1: The evolution of the task-artifact cycle in a more co-constitutive 
vision. 



Situated Action" (1987), the number of references to this construct of analysis 
has ever and ever increased, as well as the related (though not similar at all) 
concept of situatedness: a brief look at the citation trends (see Figure [5]) in the 
communities that are closest to EUSSETr^l shows how the discourse around the 
concept of 'situation' is central in system design and further proof of that comes 
from the recent initiative within EUSSET to prepare a "Situated Computing 
Manifesto" and to present such a document to the European Commission as a 
contribution to the new research program of the European Community called 
"Horizon 2020" with the aim to open a "new" research area inside the program 
focused on research on human practices and design of new svstemj^l. 
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Figure 2: Trends in scholarly citations for the terms 'situated action' and 'situ- 
atedness'. 

Notwithstanding its relevance, this focus on "situation", rather than on per- 
formativity, resulted in being problematic, perhaps for its apparent roots in the 
concept of a (static) place (cf. Latin situatio, site) that laid it open to repre- 

38 The query was performed on the 16th of October 2012 on Google Scholar and was ex- 
pressed as follows: ('situated action' OR 'situatedness') AND ('CSCW OR 'HCT) AND 
design). 

39 http: / / www.thinkinnovation.org/it /blog/2012/ 06/eusset-has-just-engineered-the- 
manifesto-of-situated-computing/ 
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sentationalist drifts (cf., e.g., the conn otations a c quired by the term 'context', 
among which that of "container-like" ( Suchman . 20061 p. 19 ), in IT- r elated 



discourses about "context- aware systems"). As pointed out by IClancevI (|1997 . 
p. 23), "the overwhelming use of the term situated [■■■] since the 1980s has 
reduced its meaning from something conceptual in form and so cial in con t ent to 



merely "interactive" or "located in some time and place". Even lSuchmanl (|2006l ) 
herself admitted that the passage where she had written that "the situation of 
action can be defined as the full range of resources that the actor has available 
to convey significance of his or her own actions and to interpret the actions of 
others" could be erroneously "taken to imply that 'the situation' exists somehow 
in advance of action and that it could at least in principle be fully enumerated 
and represented in the form of a model to be referenced" and drawn by some pro 



fessio nal (i.e., the designer) before actually going "where the action is" ( Dourishl . 



200lh . Conversely, "the sense of the situation [Suchman is] after is a radically 



performative and interactional one, such that action's situation is in significant 
respects constituted through, or stands in a reflexive relationship with, ongoing 
activity" (p. 125, our emphasis). 

This remark can not be underestimated. Indeed, when Suchman exposed the 
main themes pertaining to her decades long research in the field of HCI in the 
preface of "Human-Machine- Reconfigurations" (a reprint of "Plans and Situated 
Actions" that was enriched by new footnotes and additional chapters) she men- 
tions: "the irreducibility of lived practice, embodied and enacted; the value of 
empirical investigation over categorical debate; the displacement of reason from 
a position of supremacy to one among many ways of knowing in acting; the 
heterogeneous socio-materiality and real-time contingency of performance; and 
the new agencies and a ccountabil i ties e ffected through reconfigured relations 
of human and machine" ( Suchmanl 20061 xii). It is for us extremely indicative 



that Suchman did not mention "situated action'^], nor situatedness. Here we 
briefly recall that the former concept was originally chosen "to underscore the 
view that every course of actional depends in essential ways on its material and 
social circumstances" (p. 70); on the other hand, the latter term was actually 
never used by Suchman, although hundreds of scholarly papers associate it to 
her worlQ and h as been o bject of some criticisms, among whicfF^I we recall 
here the point by ICiboira ( 20061 ) regarding the paradoxical and somehow ex- 



traordinary lack in such concept of any affective, human, but we would also say 



40 Perhaps a sort of semantic pleonasm if it is true that action can not be but situated. . . 

41 including planning itself or "calling out a plan as a self standing artifact" cf. , respectively 
p. 17 and 21. 

42 As a matter of fact, in Human-Machines Reconfigurations Suchman speaks of situatedness 
only once, and only to challenge the meaning intended for such term by Rodney Brooks, the 
MIT engineer that questioned symbolic representational approaches in the field of robotics, 
as she found such meaning "evacuated of sociality". 

43 In this number we can also mention people, like lLave~a nd Wengei] dl99lT) lamenting the 
vagueness of the definition itself of si tuated ness, as well as, from an exactly antithetical stance, 
other scholars, like Vera and Simon (1993), contesting what they think to have understood of 
this concept. 
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performative, eleme nir^. In the same vein, also t he current interests on either 



situated software" ( Balasubramaniam et al . 20081) or "situated computing" can 



be questioned. As Suchman put it (our emphasis): 

I believe that the argument made [in 1987] holds equally well today, across 
the many developments that have occurred since. The turn to so-called situated 
computing notwithstanding, the basic problems identified previously - briefly, 
the ways in which prescriptive representations presuppose contingent forms of 
action that they cannot fully specify, and the implications of that for the design 
of intelligent, interactive interfaces — continue to hau nt contemporary projects 
in the design of the "smart" machine {Suchman, 2006, p. 3, our emphasis ). 

Thus, we observe how, periodically in the IT system design discourse, terms 
and expressions that do have the potential to overturn the traditional op- 
positions like those of abstraction vs. materiality, representation v. perfor- 
mance, and that o f design of system s that "solidify and stabilize procedures 



and classifications" (lOrlikows ki, 1992aj) vs. their use in situated performances, 



although they are "sensitizing concepts" "which draw attention to importa nt fea- 



tures of work and provide guidelines directing research in specific settings" ([Crabtree et al 
l200ll) . nevertheless end up by getting themselves into a sort of seventh room 
of the Bluebeard castle, where concepts are seemingly kept alive, honored and 
dolled up, but actually in a state of harmless captivity, with no real influence 
on actual practices and on the inner convictions of practitioners. This could be 
just the plain consequence of having "engineering education had over-invested in 
analytical technique and scientific understanding at the expense of the practical, 
'hands-on', the creative, the refle ctive, the social, the constructive, the ethical, 
the economic" (|BucciarelliL liool . p. 295). Or maybe of just opening the wrong 



doors. 

In conclusion, we assert the topicality of the performative turn (especially in 
the sense of the intellectual legacy argued above) and advocate the concept of 
performativity to be taken more seriously in the future for at least two reasons: 
first it refers to a "doing" explicitly, and in that it differs from the keywords like 
"situation", "situated(ness), and "context" which all refer to a "state of being"; in 
the hope that this could be enough to avoid getting sucked into the Charybdis 
of essentialism/representationalism, this could also facilitate the reappropria- 
tion of the original lesson by Suchman, at least within the CSCW community. 
Second, we believe that the performative view, in its being anti-conceptual, 
anti-representational and against surreptitious divides between design and use 
(i.e., practice), have a potential t o bring us on the oth er side of the river (cf. 
the life-raft model me ntioned by Buescher et al . [200lh ) and let us assert that 



technology- in-practice ( Orlikowskif 2000 ) can not be really "designed" but rather 



allowed to "emerge'o, and finally shift with no regrets our concerns "from a fo- 
cus on invention [we would say of design, Ed.], understood as a singular event, 



44 ICiborral l|2006h writes: "'Situated' is the translation of the German 'befindlich'; situat- 
edness is 'befindlichkeit'. [The former term] not only refers to the circumstances one finds 
himself or herself in, but also to his or her 'inner situation', disposition, mood, aflectedness 
and emotion.". Moreover incidentally, we could also note that the German courtesy expression 
"Wie ist Ihre Befindlichkeit?" can be translated "How are you doing?". 

45 Of course some has still to develop the technological artifact. 
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to an interest in ongoing practices of assembly, demonstration and performance. 
The shi ft from an analysis in terms of form and function to a performative ac- 
count" ( Suchman et a I I2002L p. 165). We re-propose this resolution within our 
alternative mythology as a way to bridge the literature contributions mentioned 
above and the following discourse on bricolage. 



5 From concepts to 'bricolages 1 

I often try out little bits 
wheresoever they might fit. 
The sages call this bricola ge. 
the promiscuous prefer menage. . . P D I 

If the discourse on complexity suggests that complex systems, and in par- 
ticular socio-technical systems, can not be really designed; and the discourse 
on the performativity nature of socio-technical systems suggests us to recognize 
that designing for interaction and action is overambitious for its irreducible dis- 
tance from the actual performance of the task (which actually, ultimately and 
yet continually creates meaning and materiality in a situated setting), the last 
discourse we aim to in order to build our mythology is what gives us "some 
hope", that a way, if not a meth od, can be taken toward the actual realiza- 
tion of technological scaffoldings ( Orlikowski . 2006h for collaborative complex 



socio-technical systems: the discourse on the bricolage. 

As many other authors before us, in very different fields, we are also fasci- 
nated by what the word "bricolage" evokes, both in light of its etymology, which 
differently from what it is usually reported can be traced bac k to old expre ssions 
meaning to 'stray', 'swerve' but also 'reb ound', 'redound' (Millerl . ll996lF^I . as 



well as in light, of course, of the research iLevi-StraussI (|1966f ) accomplished on 
mythical thought and so called "primitive" cultures that he reported in his book 
'The Savage Mind'. The word itself legitimates the fact that this concept has 
been adopted in different fields and that it happily "redounded - itself a bit of 
bricolage - to other disc ourses: postm odern philosophy, theology, depth psy- 
chology, literary theory" ([Miller . Il996h . cultural studies and IT design-related 
research. In this latter field, we draw heavily on the concept of bricolage for 
its "overall generative effect], which] seems to be more dependen t on interaction 



rather than on some overriding design rationale" (our emphasis Lanzara , 19991 



p. 347) and because "bricolage privileges combinatory logics, loose coupling, 
and garbage can processes" {ibidem), right the elements that are suggested by 
the certainty that any designed thing, no matter how well conceive d, will nec- 
essar ily fall short of avoiding the "law of unintended consequences' ' (|Mansfieldl . 
201fl ). 



46 Thomas Erickson, 2000, allegedly written upon reading a commentary for a special issue 
of CSCW Journal on Theory. 

47 so that it is fully justified to claim that bricolage pertains both to an indirect, unexpected, 
somehow deviating action (cf. The Oxford English Dictionary) but also to something that is 
essentially redundant and "inefficient", at least with respect to some modernist views. 
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To our knowledge the first authors to draw the rich semantic sphere hovering 
around the concept of bricol age nea r to th e equ ally rich s phere regarding design 
were (almost independently) IWeickl ( 19931 ) and Ciborra (1992) in the close am- 



bits of organizational design and information systems design, respectively. These 
studies, although kept themselves mainly abstract and theoretical in analysing 
the value of adopting the bricolage metaphor in the design research, provided 
the conceptual background for many subsequent contributions that leveraged, 
or simply were inspired, b y this metaphor . Amo ng these, we also consider the 



impressive contribution by iBuescher et all ( 2001 ) that was one of the first ones 



to try to give more concreteness to the notion of bricolage within the factual 
process of the development of co mputer-based i nform ation systems in organi- 



zational settings. In their work IBuescher et all ( |2001|) suggestively propose a 



"life-raft" model of systems development - a continuously unfolding bricolage 
of technologies to hand, requiring much patching and baling, with an unknown 
destination'' (p. 17). In this "overarching framework within which newly devel- 
oped technologies are set in place and helped to 'work'", they argue that the 
design process had to become more "immediate and continuous" in order "to 
cope with the deeply built-in uncertainty of the relationship between techni- 
cal systems and work practices" (p. 22). Differently from other authors, they 
provide a pretty concrete definition of bricolage in a CSCW context: 

Bricolage can be described as 'designing immediately', using ready-at-hand 
materials, combinations of already existing pieces of technology - hardware, 
software and facilities (e.g., Internet providers) — as well as additional, mostly 
'off-the self ones. It therefore also involves design as assembly [and] requires 
investigation of the process of assemblage as well as designing for it. (p. 23) 

While we could substantially agree with the point regarding the immediacy 
of a bricolage-oriented approach (which we interpret as 'unmediated spontane- 
ity", i.e., "without the mediation of designers or IT specialists", rather than in 
terms of "ad-hoc quickness"), we look with diffidence the subsequent points that 
bricolage "is not just an assembly of technical components, but also of appropri- 
ate workpractices, skills and training, communications, affordability, legal and 
contractual arrangements, etc." (p. 23) 

In fact, if bricolage can at the same time be considered as "a description of the 
existing context"; the general activity of bricoler as well as as its "(unforeseeable) 
outcome" (i.e., an assemblage of 'things that work', the solution coming out 
from a particular round of development); and even as a (presumably context- 
independent) "method for design", we would agree to face a very rich concept 
but, at the same time, we would consider it a far too all-encompassing one to 
really support a factual approach to system development. 

For this reason we propose to focus on the notion of bricoleur, i.e., who 
performs bricolage , and there f ore es pecially on the notion of the bricoleur-in- 
practice (to mirror Orlikowski ( 2000l ) terminology), i.e., who is actively involved 



in the activity of bricoler, and we submit such an idea of user as the one intended 
to get value from a bottom-up approach to technology development that tries 
to do without conceptual design (although not ne cessarily without "desig ners", 



to do without conceptual design (although not necessarily without desig i 
as we will see in Section 173]) . As put in words bv lHartswood et"al ( 2000h : 
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Users need the opportunity that only their work can offer to explore fully 
the possibilities for adopting, and adapting to, new systems and artefacts. When 
this is allowed to happen, and given the right choice of technologies, development 
work can assume the characteristics of 'bricolage' — i.e., the rapid assembly 
and configuration of 'bits and pieces' of software and hardware — led by users 
acting within their own work settings, with IT specialists taking on the role of 
facilitator. 



Yet, for the detrimental nuance that the term bricoleur has in French as 
well in its closest English translation 'tinker', we propose to denote the expres- 
sion bricoleur- in-practice in terms of the single term "bricolant", i.e., "who is 
performing bricolage". This is the meaning that we want to adopt and that 
we trace back to the specific archetype of bricoleur that Levi-Strauss himself 
introduced to contrast the opposite archetype of 'engineer'. In our view, then, 
the latter can personify the rational designer that builds systems from scratch 
after and in virtue of a conceptual effort; while the former denotes the user that 
fabricates her own tools from available resources, being immersed in situated 
performances and contingencies. 

The bricoleur is adept at performing a large number of diverse tasks; but, 
in contrast to the engineer, he does not subordinate each one of them to the 
acquisition of raw materials and tools conceived and procured for the project: 
his universe of tools is closed, and the rule of his game is to always make do 
with 'what's available', that is, a set, finite at each instance, of tools and ma- 
terials, heterogeneous to the extreme, because the composition of the set is not 
related to the current project, or, in any case, to any particular project, but 
is the contingent result of all the occasions that have occurred to renew or en- 
rich the stoc k, or to maintain it with the remains of previous constructions or 
destructions l|Levi-Straussl.ll966l . p. 17). 

For our aims, the key points and motivations for focusing on the role of 
the bricolant bricoleur, and hence on the performance of bricolage (or bricolag- 
ing), rather than on its outcome or the corresponding a-t emporal activ i ty, i.e ., 
the bricolage, is somehow buried in three statements bv iLevi-StraussI ( 1966f ). 



In what follows, we will review these three passages to some extent, for their 
importance in making our position more clear. First, objects "are not known as 
a result of their usefulness; they are deemed to be useful or interesting because 
they are first of all known" (p. 9). This means that what is "useful" or not 
cannot be pre-determined in terms of functional requirements, irrespectively of 
the competence of the analyst/designer, as these are necessarily decoupled from 
the actual availability of the corresponding functionalities in the workspace of 
users. Conversely, each work item, be it both operator or operand of a computer- 
based functionality, is meant by users as useful if they have already internalized 
its function, that is if they already know it and have made sense of it. This 
means that the bricoleur is certainly someone that uses the objects she can 
find around her, but it is also necessary that she has previously been somehow 
involved in the creation of those objects, so that she can really know them and 
know how to arrange them meaningfully at any time. Thus, bricolage is seen 
as an arrangement of predefined objects, where pre-defined here just means 
"defined before" and not "from above by someone else". 
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This lead to the second passage where a distinction between the engineer/ 
designer and the bricoleurs is made in virtue of "the inverse functions which 
they assign to events and structures as ends and means, [the designer] creating 
events (changing the world) by means of structures and the 'bricoleur' creating 
structures by means of events." (p. 22). This point is particularly important in 
the vein of how the performative stance sees every eventful. This means a word 
of caution regarding any structure that the designer could conceive to either 
enable or constraint action (i.e., change the world) as these structures may be 
changed in the proces s of their enactment, even if such a change is unintentional 
and unacknowledged (|Orlikowskii [19960 It also relates to the more manifest 



feature of the bricoler (that is the activity of bricolage): not only, as said above, 
to make things out of the materials one has lying about, but also to make sense 
of those materials according to an interpretative act that reinvents the objects 
(at least their meaning, their function, their value) anew in face of change, 
and that is hardly anticipatable and mostly unplannable as it is also deeply 
conditioned by past interactions (we would also say 'situated' of course). Thus, 
we can say that change urges the bricolant user to modify her bricolages, as well 
as its building blocks. 

This leads to the third, and more important, passage to our aims: "the en- 
gineer works by means of concepts, and the bricoleur by means of signs" (p. 
20), in light of the fact that "signs can be opposed to concepts [in that] whereas 
concepts aim to be wholly transparent with respect to reality, signs allow and 
even require the interposing and incorporation of a certain amount of human 
culture into reality" (p. 20). The idea of transparency from this passage hints 
suggestively at a clear development recommendation: whereas the engineer aims 
to hide information^] and to make his idea of, say, Patient into a number of 
attributes codified in a relational DBMS, well underneath the application logic, 
the bricolant user needs to have well under his gaze what fields will represent the 
patient in her artifacts, arrange them the way she needs, fill them in on the basis 
of informal conventions and customs, as well as to disregard and create some 
new attribute/field at need irrespective of any ideal model of that disembodied 
entity. Moreover, the passage mentioned above also clearly requires, first, that 
a second but by no means less important activity of the bricolant user follows 
the activity itself of having built the bricolage (the artifact), and consists in 



48 That is as "an autonomic and contingent occurrence with its own conditions and its own 
time-structure, [in res pect to whichj the meaning of th e past for the present is not fixed but 
radically ambiguous" (Dirksmeier and Helbrecht, 2008), i.e., inextricably intertwined with the 
given situation. 

49 As Derrida has cunningly observed, there is an inverse relation between p lay, to whic h 
bricolage as an irrational, nonlinear and fragmented activity can be assimilated l|Pohnl.l2007h . 
and structure. If one of the most ambitious purposes of our mythology is to challenge 
this distinction by highlighting the supremacy of use over design, we owe to Derri da the 
insigh t that also this dichotomy is a myth, "simultaneously meaningless and useful" {Pohn, 
120071 ). which is itself made up, and probably fostered by "t inkerers of abstractions" who 
try to sell representational serv ices to potential customers (Robinson and Bannor], 1 199 it 
iNandhakumar and Avi son, 1999) 

50 Cf. the principle of encapsulation, which is defined by Grady Booch as "the process of 
compartmentalizing the elements of an abstraction". 



27 



a continuous and seamless accumulation of any sign that could help her make 
sense of the bricolage-in-practice: so content can enrich the bricolage-artifact 
(not just "be contained" or "stored" therein), as well as any kind of meta-content 
produced by the users can, like comments, tags, nested threads of conversations 
that unfold around and about the tangible artifact. In short: bricolage as a con- 
tinuous and creative "playing with signs'!^]. Second, this passage sheds light on 
the requirement that any computational support of the activity of the bricolant 
user (i.e., the bricoleur at work) must be oriented towards this continuous cre- 
ative and i nterp r etativ e activity (that can accumulate data as well as coordinate 
activities (jBerei Il999h ). which nevertheless is completely on her own; towards 
the reconciliation of multiple, possibly diverging, interpretations; and above all 
towards the coexistence of these multiple and contextual incorporations (see 
above), both in the local and in the global dimension. 

This latter point is what makes us believe that the bricoleur-oriented mythol- 
ogy (as a specific kind of end user, or better yet, of end user enabled by a specific 
kind of platform that we will outline in the next section) does have the poten- 
tial to oust the designer-oriented mythology, or at least the mythology where 
the designer is the proverbial Renaissance figur e able to exhibit the compe- 
tence, in short what iHirschheim and Klein (1989) in a still timely contribution 
denoted as the "systems expert". This stereotype, although it has been con- 
sidered "unrealistic and an arrant nonsense" for more than 20 years within the 
CSCW community, still distorts in professional practice (and not only there) 
the fragile symme try of the Janus-like relationship between users and design- 
ers (jBowersl Il99lh . In the next sections, we will speak about how a "laissez 
faire les bricoleurs" method can be flanked by a specific " logic of bricolage", in 
order to empower end users and have them become the builders of their own 
artifacts within their daily practices. 



6 Towards environments that support the bricoleur 

Everything that can be said, can be said clearly. 
(Ludwig Wittgenstein, 19220 

In this section we would like to address how the three discourses that we have 
outlined above can converge into a single, coherent and practical proposal for 
the development of interactive and collaborative information systems. If these 
strands can actually converge, the related mythology of system development 
should situate itself among the relatively new researc h lines that a re em erging 
within the HCI field. As also recently pointed out bv lArdito et al ( 20121 ) these 
lines focus on concepts such as: 



51 This passage is strongly influenced by the reading of Nieztsche by Derrida in "Structure, 
Sign, and Play", where the Nieztschean perspective is related to "the joyous affirmation of 
the play of the world and of the innocence of becoming, the affirmation of a world of signs 
without fault, without truth, and without origin which is offered to an active interpretation.". 
Bricolage itself is a concept that urges us considering system development as a game-related 
social underatake. 

52 Tractatus Logico-Philosophicus, 4.116 
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Appropriation: i.e., the process by which technologies are understood and 
used by users in their own ways, po ssibly subverting the designers' inten- 
tions (lOrlikowskil Il992ri 151x1 12007T) . 



• Meta-design ([Fischer and Giaccardil 120061 ): also denoted as "design for 
designers", a design paradigm, which allows various stakeholders, includ- 
ing end users, to act as codesigners even at use time; according to this 
paradigm, software engineers do not design the final application, as in 
traditional design, but they create software environments through which 
different stakeholders can contribute to the design of the final application 

• End- User Development ([Lieberman et al . l2006h : a paradigm that focuses 
on the capability of systems to offer support during run time to empower 
users to develop their applications, blurring the distinction between design 
time and run-time; 

As we will argue in what follows, the alternative proposal we advocate moves 
from the first concept of those mentioned above to the last one, in a progressive 
approaching towards its gist tenets. The term appropriation is indeed represen- 
tative of a stance we desire to distinguish ourselves from since it is clear that one 
can appropriate, i.e., take as o ne's owrF^|. a "thing" that has been constructed 
by someone else. For instance, ICarrollI (|2004l ) writes of "the crucial role played 
by users' actions in completing the design process" and that "[technology ap- 
propriation] is actually part of the design process. The design of a technology 
innovation is completed by users as they appropriate it". We find then that the 
notion of appropriation is deeply ingrained in the design-oriented rhetoric. 

In the same mould, also meta-design is a term that explicitly refers to the 
phase of design, and that was programmatically aimed at investigating "tech- 
niques and processes for creating environments that allow 'owners of pro blems' 
(or end users) to act as designers" (our emphasis, Fischer et all . 2004). The 
main contribution that we want to retain from this framework is then the idea 
of "underdesign"; this notion relates to design for purposely "incomplete" sys- 
tems that, once deployed, would allow for important modifications by end users 
themselves, in face of unexpected needs that show up at use time, and that 
could not be anticipated at design time. Underdesign hints at a conceptual de- 
sign that does not have the ambition to fully set the system up for its embedding 
in a complex socio-technical system, but it also hints at a design for the "under- 
layers" i.e., aimed at the construction of environments where applications can be 
developed with a strong inter action (co-design) between users and professional 
designers. iFischer et all ( 20041 ) use the term "seed" to denote an underspecified 
application that users can complete during its use; the authors of this work also 
report about the action research initiatives that led to the construction of such 
environments by means of specialized editors (e.g., a Map Editor). The term 
seed is fully coherent with the idea that applications grow (|Truex et all . Il999h 



53 One could notice that the Latin root of the word appropriate, i.e., ad-propriare, hints 
more at a taking than at a making (cf. the preposition ad here indicates a motion toward 
oneselves.) 
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and evolve with their environments but, in some way, this latter idea seems to 
clash with the claim that that end users have to act as designers, if this means 
to reiterate a conceptual, detached and abstract if not formal way to envision 
how the application ought to be and ought to behave in the unknown future, 
even if this activity is performed by end users, who play the "designer" role. 

Moving in the same direction but covering some road further, EUD is the 
approach the most clearly and explicitly has stated in its agenda (as well as 
in its name) the involvement of users in the construction of their technology, 
and without expecting them to act as designerj^l. This shows a strong affinity 
with the approach we are going to discuss, especially if the meaning at stake for 
the term 'development' is the original one mentioned in Section [TJ that is the 
notion of a continuous and indefinite (not necessarily teleological) "unfolding" 
over time, pruned of its abstraction and differentiation from the actual work 
practices; only in this way, the end user is left in her natural, or better yet 
ecological, environment, and she is not eradicated from her work situation to 
be transplanted, within another well circumscribed and protected environment, 
into the engineering framework of "coding for designed structures". This is the 
point that resonates more with the passage by Levi-Strauss reported in Section[5] 
where the end user, the bricolant bricoleur of our mythology, is expected to 
"work with signs instead of with concepts". Thus, constructing (or modifying) 
the artifact should not be seen as radically different than working with the 
artifact. The constructs and structures with which the end users work should 
be familiar (cf. the other passage highlighted in Section [5]) , like blocks and 
parts of the artifact itself, are indeed conceived to be rearranged or created by 
composition from smaller subcomponents that are not ontologically different 
from their compounds (e.g., big field sections in forms are made of smaller fields 
groups, and these in their turn are but data fields). 

Adopting a fully and coherent EUD approach has a strong impact both on 
the dimensions of who is involved in the development; and what kind of system 
is supposed to support this kind of developing. We will discuss both these 
dimensions, starting from the more general one, which regards what application 
macro-classes must be considered for a platform that supports the continuous 
bricolage-based construction of convivial toolsWi 

54 As every rose has its thorns, also the expression End-User Development has actually its 
own; ironically one could find a little thorn for each single word therein contained. End: this 
reiterates the concept of an actor who is the ultimate terminal of a process that she does not 
control or owns, as indeed she comes at the end of it; user: this reflects the idea that an 
artifact is built and then used, and that some actors design it and some others just use it; 
development: this can hint at the fact that the more the end users are able to develop their 
own tools in the traditional sense of the term (i.e., by programming it) the better it is, and 
that EUD research is mainly concerned with filling in the gap between this ideal vision and 
drab reality. Although we take this exercise in a tongue-in-cheek way, we can nevertheless 
make a more serious link to our advocacy of more deconstruction-oriented analyses of our 
given-for-granted categories and discipline language in the quest of (some of) the deep reasons 
why IT research has such a low impact on IT professional practice (see Section . 

55 This expression is taken from Illich. A convivial tool is defined as "that which gives each 
person who uses it the greatest opportunity to enrich the environment with the fruits of his or 
her vision" and whose "renewal would be as unpredictable, creative, and lively as the people 
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6.1 What meta-system for end users' systems? 

It is possible to distinguish between two main ways a system supports the de- 
velopment of an application at the level of the end users or at least for its tight 
adaptation to their needs, that is two main ways such a system can act as a 
sort of meta-system for the development of EUD systems. On the one hand, we 
can consider systems that primarily (or exclusively) support configuration. This 
regards the so called "flexibility through control" of systems that offer ways for 
pe ople to adjust s ettings, reprogram the system or otherwise technically adjust 



it (|Dourishl .lT999). Yet, allowing the setting of more or less articulated parame- 



ters that affect the application's behavior or its appearance at the interface level 
entails to give end users little room for intervention, as this is limited to a set of 
elements that can only take one from a predefined (at design time) set of values 
and corresponding effects on the application at run time; accordingly, such sys- 
tems allow for an involvement that is, to our aims, too superficial (also literally 
speaking) and that comes up by being constrained by some model of feasible ac- 
tion, or better yet by some feasible pattern in the "fitness landscape " (|Mansfieldl . 



201Ct p. 50) that results from precise configurations in the "design space" 



On the other hand, oth er kinds of sy stems offer an environment that is 
"flexible through openness" (|Dourish , 1999), that is a sort of "meta-system" by 



which users are supported in the creation of new systems and applications of 
different complexity, according to their needs and competences: macro pro- 
gramming, visual programming, programming by demonstration are among the 
solutions that are given to users to "encourage their participation in the design 
process" ( Dourishl . 200l[ p. 170). Here the risk may arise that the good motiva- 



tions and purposes of EUD-oriented researchers may clash with the scope and 
aims of the actual tools that are made available to the end users: specific features 
of the environment (or their absence) can introduce, or even impose, rigid models 
of practice, possibly unaware, and affect how end users build and maintain their 
equipment. This point relates to an important feature that environments en- 
abling EUD practices should possess: we call this quality universatility, to hint 
at something in between the traditional qualities of generality, universality and 
versatility. While generality is usually defined as "the degree to which a software 
product can perform a wide range of functions" ( Khosravi and Gueheneucl . 12004 ) 



and hence serve multiple purposes, universality and versatility (from which uni- 
versatility) refer to the qualities of being both general-purpose, but also easily 
tailorable to the needs of specific settings and thus able to fit local needs. In 
other words, where generality refers to the typical quality exhibited by Swiss 
army knives, that is to have multiple specific functions to serve distinct but 
anticipated purposes, universatility refers to the typical quality of Sardinian 



who use them" llllicbl lll973r ). This term then evokes a concept that is central to both the way 
we intend bricolage, as a collaborative and creative activity, and technology, as a tool also for 
socialization, not only for efficient production, whose building and development should give 
the opportunity to "end users' to collaborate and socialize. From Latin con-vivium, living 
together, having a nice time together, a convivial tool is a tool that unites people in both its 
use and production, that does not alienate them and indeed give them opportunities to enjoy 
life together. 
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Pattada knives^, that is to allow for an open space of possible usages by which 
users reach their unanticipated purposes with creativity and autonomy. Thus, 
a powerful environment has to be uni-versatile enough to avoid imposing re- 
strictions on the applications that it allows to construct. Here the core of the 
problem lies in how this quality is guaranteed and on what conceptual premises 
(i.e., myths, to recall the vocabulary introduced in Sectionf!) is grounded on. 



Universatility based on an ontological approach The first way to 
make an environment general enough to be applied to any cooperative set- 
ting but also versatile enough to fit any (in principle) of its situated tasks is 
what we call the "ontological approach". This is expression of the represen- 
tational and objectivistic approach we discussed in Section 01 the designer of 
the environment decides how to guarantee wide customization on the basis of 
a pre-understanding of how actors behave in a number of recurring situations 
in multiple domains; consequently, on the basis of this understanding (which 
is based on deep introspection or more interactive and qualitative techniques), 
the designer conceives a set of "labels" that univocally identify the "things" that 
users will handle, associates that classification scheme with intended universal 
building blocks, and provides users with those elements, all together with spe- 
cific rules for their composition, so that they can (acknowledge and) make value 
out of that g iven model. A pa radigmatic example of this approach was the 



Coordinator ( Flores et al . 19881 ) 25 years ago: there the ontological claim was 



that actors coordinate their actions in terms of negotiation of commitments, and 
according to this model the technology offered a universal set of possible cate- 
gories to characterize setting-specific behaviors and routines. The assumptions 
underlying this technolo gical proposal h ave been widely discussed, and con- 



trasted, since then (e.g., ISuchmanl . 119941 ) but other examples of this approach 



still abound, both in daily life, e.g. where reference management softwares force 
us to univocally associate our academic works or books with a specific category, 
and in recent academic research, e.g., when users are calle d to categorize others ' 
comments in public discussion with a system like Reflect (jKriplean et al l2012f ) . 

In addition to systems where the ontological approach is adopted in an ex- 
plicit form, we notice that such an approach can also act within an IT system 
implicitly (if not surreptitiously), especially in all those systems that adopt a 
characteristic or strong metaphor representing "the" one way in which human 
allegedly organize their world and practices: this is the case of the most famous 
(and nowadays notorious) "desktop metaphor ", as well of some recen t alterna- 
tive, like the metaphor of "story" proposed bv lDe Michelis et all ( 20091 ): in both 



cases, users are called to associate the objects they work with with a concept 
(i.e., the notion of file, or of resource) and characterize it in terms of a cate- 
gory - being it the name of the folder in which the file is virtually stored (as 
well as the location of this latter in the "file system"), or the name of a sequence 



56 A pattada is "an Italian pocketknife [dating] back to the 15th century, [that] is a folding 
model that opens to a length of 15 to 35 cm [and thatl farmers and shepherds always carried 
it with them to do all sorts of jobs in the fields." (De Michelis, 2003) 
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of interactions with someone or about something (i.e., the topic of a conversa- 
tion) . The same phenomenon occurs in the ambit of context-aware or situated 
computing where, as mentioned in Section |H tools to characterize a context or 
a situation are part and parcel of the design of the application itself, whenever 
this task occurs, and they are based, again, on a predefined domain model that 
the users can only customize (or appropriate); this seems in basic con t rast w ith 



the idea of context as "embodied action" that we share with iDourishl (|2004f ). 

All these approaches, either explicitly or implicitly ontological, are grounded 
on the hypothesis that things could be described univocally or, at least, that the 
"name for a thing" would mean that thi ng irrespective of the setting where suc h 
name is used, and for what aim (cf. e.g. iMark et all . l2002t I Anderson et all . l2008f ): 



this is the essence of an ontological stance. However useful this approach may be 
for ordering and retrieval purposes, any more or less structured "ontology" (in 
the broadest sense, i.e., taxonomy, classification scheme, interaction metaphor 
and the like), this is conceived at design time and it is given to the users so 
that they make sense of their world in a way that can make some tasks more 
orderly efficient; yet, this way, counterproductively (cf. Section [T]), may also 
hinder the construction of supports of other, possibly more "hidden", tasks: this 
mirrors platforms that provide users with functionalities that allow for some 
degree of tailorability but, as the latter is constrained within the boundaries of 
the metaphor itself, do not encompass functionalities to let the application (and 
its underlying ontology) evolve towards and align with the idiosyncratic customs 
of the users: the availability of such functionalities, and their subsequent use, 
could seriously undermine the consist ency of the ov erall model, and hence the 
effectiveness of the former tasks (e.g., PetersL 20061 ). 



Universatility based on a performative approach The main tenet 
of EUD regards giving users a more substantial role in technology conception, 
development and evolution. Component design is proposed as an approach that 
allows users to tailor their applications by enriching them with suitable com- 
ponents offering specific functionalities. This would r equire the application to 



be open to such type of tailorization ( Stevens et all . 120061 ). Moreover, while 



for a ta sk of integration, "componen t thinking" could seem natural, we have ob- 



served ( Locatelli and Simone , 2010l) that in the construction of application from 



scratch this could be perceived as difficult by users, who usually see their appli- 
cation in a more holistic way than the component-base d approach would have 
them to think about. A more radical stance is taken bv lFischer and Giaccardi 



(2006) and their notion of meta-design. To this regard we have already raised 
our perplexity, at least on a purely conceptual level, regarding those platforms 
that would be aimed at making users act as "designers" (in the modern and 
irresistible connotation of the term), rather than allowing them to construct 
their tools much alike they already do with their traditional artifacts: i.e., 
by individual or bottom-up organized initiatives, trials and errors, progressive 
amendments, patchwork and bricolage attitudes. Indeed, we have observed 
that actors in their everyday (working) life do not follow a traditional design- 
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based appr oach to solve their pr oblems and to construct the tools they need 



to this aim ( Cabitza et al . 2012al); this pe r ception finds confirmation in a num- 



ber of field studies (e.g.. ICarstensen et all.ll995tlMorrison an d Blackwcll, 2009; 
Blackwell and Morrison! l20ld : lHandel and Poltrockl . l201lHMorrison etall201l]) 



that focus on non- yet-digitized settings and that show a continuity in work prac- 
tices development and paper-based tools construction that the current technol- 
ogy and the approaches used in its construction are still not able to reproduce 
or guarantee. 

Indeed, if we agree that one of the main issues here at stake is that about the 
gap between users and designers (in the traditional sense) - which is grounded, 
as we discussed in Section[5]on a conceptualization of design that will always pre- 
vent users from taking full control and responsibilitjjf^ of the development pro- 
cess - we believe that this gap can be bridged only if design, and the conceptual 
modelling activity that design implies, are simply avoided and if the approach 
toward "technology co-construction" takes work practices "seriously", by avoid- 
ing any sort of compromise at the application level and by deriving the related 
consequences at the technological infrastructure level. In this line, taking work 
practices seriously means conceiving of technology construction as part of work 
and articulation work, in the same way as paper -based artifacts are constructe d 
by the actors when they need and use them (e.g., Morrison and Blackwell , 20091 ). 



We then call the sort of universatility that platforms must guarantee be 
based on a performative approach for two reasons: first, according to an onto- 
logical approach specificity and situatedness are reached by having actors apply 
a universal model locally: such a model can be both adopted and adapted, but 
adaptation is here a sort of extension, rather than a tinkering that could under- 
mine its basic assumptions and first-class concepts; conversely, a performative 
approach guarantees such locality by delegating the users in creating essen- 
tially open, underspecified, incomplete and even ambiguous "models", which 
that notwithstandi ng are totally t heirs, b y which they can make sense of their 
do-it-yourself tools ( Cabitza et al . 2012alc ). 



Second, adopting a performative approach calls for the requirement of an 
environment that limits itself in providing primitives by which users can build 
their application in a bottom-up fashion, that is in an emergent process of tries 
and errors, and while they work, as a way to improve the odds that the applica- 
tion will really reflect and support their situated practices: if this construction 
were "extracted" from those practices and moved to a controlled environment 
of introspection, modelling and ontological representation, we believe that we 
would again tap into a less than effective ritual, roped in the tar-baby of thinking 
that the task-artifact entanglement can be really untangled without losing both 
(see Section^}. As Lanzara put it down: "systems do not only operate or change 



57 Notablv. iBeath and Orlikowskl jl994) notice how most of the user-centered development 
methodologies that put a strong emphasis on user involvement (they make the case of infor- 
mation engineering) actually relegate users to playing a passive, although present, role during 
development and, in virtue of this participation, ask a more clear responsibility for project 
outcomes. We stress here the need to give full control, rather than only responsibility, to the 
community of users that will host the information system for its construction. 
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in time, but are literally 'made with time'". Within a performative approach, 
as we discussed in Section |4l end users can be seen as bricoleurs who build their 
digital tools tapping into their tacit knowledge and their creative skills to build 
the portion of IT support that comes closer to their work practices to fit their 
needs better. 



7 Concrete Steps Towards a Logic of Bricolage 

In order to make a contribution toward the conceptual foundation of environ- 
ments supporti ng the practice of bricolage in EUD terms, we will take inspiration 



from the point Lanzara ( 1999h made on the importance of "transient constructs 



and persistent structures" (p. 332), which are seen as the results of "a practical, 
situated, context-sensitive mode of design that feeds on the dynamic tension 
between the requirements of change and stability". We also think that what he 
called the "logic of bricolage" emerges from the intertwined interplay of struc- 
tures and constructs, transiency and permanency, universality and locality: this 
requires that an environment supporting bricolage is not supposed to provide 
users with sophisticated (i.e., semantically rich) modelling tools that facilitate 
the top-down construction of the application (from the conception of the "enti- 
ties" involved, their attributes, their mutual relationships, and of the "business 
processes" where all these latter interact); but rather this logic is supposed to 
offer to the users a set of "bricks" that they can arrange and compose together 
in a bottom-up fashion within a conceptually consistent environment (the rules 
of composition). 

In order to envision such an environment, we propose a multi-layered archi- 
tecture that is inspired by the research accomplished in the COMIC project; 
in such an architecture the layers that are closer to the greater source of un- 
certainty and unpredictability, that is the layers that are closer to the users or 
where these act, are those allowed to be changed both faster and to a greater 
extent (see the column 'dynamics' in Figure [3]). With reference to Figure [31 we 
distinguish between an infrastructure, which is the set of available services that 
are used by the computational platform that is specifically designed to support 
bricolant users in building and using their own tools; this platform, in its turn, 
exposes specific services to make the bricolage-based information system pos- 
sible and computationally augmented; to this aim, the platform instantiates a 
working environment where either a persistent storage and a working memory, 
as well as an execution engine are made available to the users, and it instanti- 
ates an EUD environment where users can create their building blocks and edit 
their tools; while working in this latter environment, users use specific visual 
editors to build both their constructs and their working structures, that are put 
in operation when the working environment is "on line". 

We used the technic al terms constru cts and structures partly inspired by the 
original contribution bv lLanzara ( 19991) . More specifically, our proposal is based 



s8 The COmputer-based Mechanisms of Interaction in Cooperative work project was an EC 
ESPRIT-funded Basic Research Project No. 6225, from 1992 to 1995 
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Figure 3: A conceptual architecture for an environment supporting bricolage. 



on the following first-class concepts or elements (see the top layers in Figure [3] 
and the table depicted in Figure @|: 

constructing constructs These are constructs that we denote as such 
because they are both construct (ed) during the inception phase of the platform 
within a cooperative setting or organization as a result of participatory design- 
do activity; and they are also constructing, that is are used as atomic "building 
blocks" by which the bricoleur users can create their working spaces and arti- 
facts. We can further characterize these constructing constructs distinguishing 
between operand constructs and operator constructs: operators are all the fea- 
sible operations and micro-functions that users deem necessary to be performed 
over the operands; these latter are the most atomic data structures, compo- 
nents and variables that the platform must make available in both the editing 
and working environments to be used during situated work practices. Both 
operands and operators are the "things" that are arranged and put together in 
the bricolage activity in order to, respectively, compose the artifacts and endow 
these of computational capabilities. 
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In the same vein of Simone and Schmidt (Il993l) . we described a method to 



recognize and characterize these atomic components from the observation and 
qualitative research analysis of paper-based artif acts used within a document- 
intensive work domain (i.e., two large hospitals Cabitzal 12011 ). In Table [TJ 



we report the list of constructs identified as "operations" (i.e., operator con- 
structs) that users agreed with us they could need to apply to the "data fields'' 
(i.e., operand constructs) of their documents; these fields were identified as con- 
structs as well, as a number of these fields or groups could be used and inserted 
in multiple document templates; in the study mentioned above we called these 
atomic groups of fields "datoms", as they were documental atoms (i.e., not fur- 
ther decomposable elements) to be arranged into the needed templates. Not all 
the constructs are easy to build. Indeed, as our subsequ ent studies show, whil e 



datoms can be created with a relatively simple editor ([Cabitza et at l2011bf ). 
which we realized to allow users both create data fields and their templates, 
operations clearly need to be associated with specific behaviors exposed by the 
platform or the infrastructure (like, e.g., printing, or sending as a message, see 
Table [T] for a comprehensive list). According to the specific application domain 
(e.g., information systems, computer-assisted design), the platform can expose 
a series of elemental Application Programming Interfaces (API) to simplify the 
work of "constructing" the atomic operations to be invoked while using the ar- 
tifacts conceived for the specific cooperative setting. In general, we intend both 
kinds of constructing constructs to be semi-permanent (to mirror the Lanzara's 
suggestive naming) in that their life spans (from creation to discarding) and 
change rate (i.e., the extent they are supposed to change during their use in the 
working space) can be put on a low-changing scale (see Dynamics in Figure |4]), 
although probably the set of available operators will change less frequently than 
the set of the operands (e.g., operations and data elements, respectively). 

Structures These are what bricoleur end users create by composing and 
arranging constructing constructs together. We distinguish between layout struc- 
tures^] and control structures. The former ones are sort of material (yet non 
necessarily tangible) and symbolic work spaces that are recognized by mem- 
bers of a community of pra ctitioners as the physically inscribed technological 
artifacts ( Orlikowskil l2000h where and by which to carry their work on. In 



document-based information systems, layout structures are the document tem- 
plates of forms and charts that are to be used to both accumulate data and 
coordinate activities (Berg, 1999]), endowed of both physical properties (i.e., the 



topological arrangement of the constructs mentioned above, i.e., data fields and 
sections) and symbolic properties (the boilerplate texts, any iconic element and 
visual affordances conveyed through the graphical interface). In the domains 



59 We prefer the expression "layout structure" instead of "information structure" (or "data 
structure"), which would perhaps be the traditional mode to indicate those structures, as the 
latter term would have given the nod to the high level, conceptual element those structures 
could be referred to by a human user. Conversely, we mean to hint at the material, spatial 
arrangement of meaningful signs that "act at the surface" in promoting cognitive processes of 
sense making and interpretation. 
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Document-based Operations 


1 


create 


This operation is akin to picking a new empty sheet of 
a specific template to insert into the folder. 


2 


retrieve 


This operation is akin to picking a sheet from an 
archive and make it available for other operations. 


3 


open/read 


This operation is akin to getting explicit access to the 
content of a sheet or instance of artifact. 


4 


write 


This operation is akin to adding some new content to 
the artifact and accumulating new inscriptions on it. 


5 


select 


This operation is akin to pointing either an artifact 
(among others) or a specific portion of its content. 


6 


copy 


This operation is akin to putting some content into a 
buffer memory, like a little pocket-sheet. 


7 


correct 


This operation is to be considered different from regu- 
lar writing but rather similar to striking through some 
content and substitute it with a correct one. 


8 


transmit 


This operation is akin to sending cither the physical 
artifact or (part of) its content to an external party; 


9 


print 


This operation regards the physical printing, or copy, 
of part/whole content of an artifact 


10 


officialize 


This operation regards the formalization/certification 
of part /whole content of an artifact; 


11 


annotate 


This operation differs from write in that it is aimed at 
adding informal or side content: it stands to writing 
as metadata stands to data. 


12 


attach 


This operation can encompass affixing an external re- 
source to the artifact. 


13 


cache 


This operation regards the saving of part/whole con- 
tent of an artifact for future use (modifications are still 
possible). 


14 


store 


This operation regards the storing of the artifact in 
some repository, where only an operation of retrieve 
can take it from. 


15 


protect 


This operation regards the preservation of part/whole 
content of an artifact from further operations. 


16 


delete 


This operation regards the partial/complete elimina- 
tion of either an artifact or parts of its content. 



Table 1: Operator constructs identified in (jCabitzal . 1201 if ) 
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of computer-aided design and collaborative drawing/editing, a layout structure 
can be considered the working space where users arrange command docking 
bars, symbol stencils and predefined configurations of elements that must be set 
up before working on them. 

On the other hand, control structures specify how the computational engine 
of the underlying layers of the architecture (see Figure [3]) reacts in response to 
events generated at artifact (interface) level, how this latter acts on the content 
inscribed therein, and how it interacts with the users during their use of the 
tool. On a formal level, control structures can be expressed in terms of rewrit- 
ing systems (see Listing [T]), a general formalism that can be instantiated, e.g., 
as rule based control systems, Petri nets, Business Process Modelling Language, 
that is any sort of declarative control construct. On a concrete level, control 
structures are generated by bricoleur users by composing constructs together 
and specifying how application behaviors (that are in their turn composition 
of operators defined over operands) should be exhibited in response to events 
and contextual changes. The simplest form of control structure is a type-based 
constraint defined over some operand; we (jCabitza et all . 2009) have described 
if-then control structures (i.e., rules) by which the platform could convey infor- 
mation to promote collaboration awareness according to the content of a web of 
coordinative artifacts. More complex control structures are obtained by com- 
posing operations and selection points (defined over the constructs content) in 
a workflow-like manner. These not so transient structures (to refer again to the 
Lanzara's proposal) are intended to be both the outcome and the scaffolding 
elements for the activity of bricolage: since structures are composed by arrange- 
ment and composition of the available constructs, they are supposed to change 
at a steeper rate than these latter ones (see Figure S]): e.g., templates and rules 
defined on their content will certainly change more often than their building 
blocks, i.e., data fields and single operations. 



Primitives Primitives are basic operations that the platform makes avail- 
able through the editing environment where bricoleurs can create both their 
constructs and their structures. To adopt a pseudo-formal analogy: if constructs 
are the elements of an alphabet, the primitives can be seen as the composition 
rules of a grammar by which end users can generate meaningful sentences (i.e., 
structures). Primitives are part of the platform and exposed through the en- 
abling environment and, as such, are not expected to change too often, besides 
the traditional activity of corrective and evolutionary maintenance. Specific 
primitives allow users to populate these structures with both content and mete- 
content (see Figure^]), that is any collaborative annotation. 



Annotations We consider annotations be part of the first-class concepts 
of a logic of bricolage for their central role in work articulation, knowledge shar- 
ing and mutual understand ing (jLuff et all . 119921 : ICadiz et a i lioofllBringav et all . 
2006; ICabitza et all . l2012ah , yet at a more informal level with respect to insti- 



tutionalized (layout) structures and to the official content that is accumulated 
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<web— st ructure> :: — <layout— structure> + 
<layout— structure> ::— <topological — object >+ 

<topological— object> ::— <operand — construct> <coordinates> 
<operand — construct > ::— <constant> | <variable> | 

<functional— operator— construct >(<operand — construct >+) 
<operator— construct> ::— <functional— operator— construct> | 

<acting— operator — const ruct> 
<constant> : : — true | false | <domain— values> 

<annotation> ::— <style> <target> | <multimedia — text > <target> 
<target> ::— <control— structure> | <layout— structure> | <annotation> 
<style> ::— <convent io nal— symbol^H- 

<control— structure> ::— <rewriting — rule> | <control — structure> 

<connector> <rewriting— rule> 
<connector> :: NAND | NOR 

<rewriting— rule> ::— <guard>? < ac t ion >+ 
<guard> ::— <configuration> <condition>* 

<condition> ::— <functional— operator— construct> (<configuration>) 
<action> : :— <acting— operator —construct >(<configuration >) 
<configuration> ::— <operand — construct >+ 

Legend a : 

means 'alternative ' 
<> means 'variable ' 

+ means 'one or more occurrences'; * means 'zero or more 

occurrences '; ? means 'zero or one occurrences ' 
NAND, NOR are the universal logic that allow any logic connector 

Listing 1: A preliminary and tentative contribution to the formalization of the 
logic of bricolage 



therein during situated practice. To this respect, any form of annotation carried 
out by practitioners over and upon structures and their content can be seen as 
a more ephemeral, informal and more user-driven piece of bricolage, which acts 
at a sort of different layer with respect to primitives, structures and content 
(see dynamics and specificity in Figure [3J) but that nevertheless (or right in 
virtue of this complementarity) plays an equally important role in making the 
artifacts-in-use flexible enough to support also invisible work and hence fully 
appropriated by their users. Annotations are then either stigmergic signs and 
marks attached to the borders of documents, extempore comments, semantic 
tags from either domain specific taxonomi es or setting-specific f olksonomies, or 
nested threads of both, as we described in (jCabitza et all2012cl ): all pieces of a 
bricolage that hosts informal communication and handover between practition- 
ers, their silent and ungoverned work of meaning reconciliation, the sedimenta- 
tions of habits and customs in effective (yet still unsupported computationally) 
conventions of cooperative work; for these reasons, we believe that any work- 
ing environment aimed at enabling users in preserving (or even augmenting) 
their record-keeping conventions in the digitization of their traditional artifacts 
should support annotation as a first class activity of workers in their natural 
"ecosystem"; In particular, the n, also annotations should be referrable in control 
structures as we described in fCabi tza and Simon 3. l2012al p. 232). 
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Figure 4: Synopsis of the main concepts encompassed within the proposed "logic 
of bricolage". Specificity, scope and change rate (dynamics) of each concept is 
indicated; the number of stars and plus signs indicates the extent an instance 
of each concept is, respectively, specific and fast-rate changing. 



7.1 Some first implications on research 

The three-layered architecture described above and depicted in Figure[3]is aimed 
at addressing the user-centered requirement to provide shop-floor practitioners 
involved in a digitization program with (at least) the same space of possibility 
they have when they work with non-digitized artifacts, mainly by decoupling 
such a requirement from those of who could actually initiate such a program: 
top management (the buyer) would get the services they pay for, i.e., ratio- 
nalizing the bureaucratic administration of their firm through the i nformated 
control of communication and knowledge (jZubofi 119881 : lYatesl Il998h , from the 
infrastructure-platform stack; on the other hand, end users would get the op- 
portunity to transition from their paper-based artifacts to computationally aug- 
mented ones by means of the editing and wo rking environmen ts, so that the 
layout structures that scaffold their activities ( Qrlikow ski. 2006) would change 
with the necessary gradualness (or don't differ at all). At least in theory. 

To this win-win aim, the model is left purposely flat, general and simple: 
we do not want to introduce surreptitious entities, like the concept of artifact, 
activity, task, role and the like, which conversely traditional methods of software 
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production employ as either scaffolding or means for the phase of design. We 
have already recalled how any design of IT technologies either produces or adopts 
a model, sooner or later. These models, irrespective of the layers at which 
they manifest or are adopted, will necessarily end up by confli cting with work 



pract ices (for a recent account on this phenomenon see, e.g. Morrison et all . 



20111) . because these latter "by definition" change over time and make sense only 



in their doing (see Section@|, while models as much "by definition" introduce the 
level of representational stiffness that is necessary for their role in requirement 
elicitation and forma l specifications (e.g., Bowers . Il99lt [Robinson and Bannon . 



199lHBannonl . 119941 ). 



Yet, the architecture depicted in Figure [31 irrespective of its simplicity, re- 
quires a radical change of perspective for all the stakeholders involved in technol- 
ogy conception and construction. In particular, this proposal requires to focus 
on the idiosyncratic and fine graine d ways in which users cope with unexpected 
change in their work environment ( Bannonl . Il992fh For IT professionals this 
means to focus on how constraints have to be dynamically expressed to support 
the definition of the appropriate orderi ng of action and interaction in coop- 



erativ e work in any circumstance (e.g. Pesic et al 120071 ; Ivan der Aalst etal . 



2009); which pieces of information are used to support articulati on and cooper 



ative work and how these are arranged in suitable artifacts (e.g. Nemethl . 120031 ; 



Cabitzal 120111 ); what habits, customs and conventions are at stake and silently 



inform the exchange of information and th e sense mak i ng occurring within and 
across communities of cooperating actors ( Markl 12002 ; Cabitza et al , I2009T ) . In 
sum, conceiving artifacts (and entangled tasks) as more or less transient "enti- 
ties" emerging from the composition of constructs requires to understand what 
elementary bricks users already have on hand to flexibly compose their artifacts 
(remember the requirement that bricoleurs already know the available pieces) 
and to conceive of ways to make those bricks computational, that is, associated 
to specific system behaviors (or functionalities), so that the performative and 
entangled nature of tasks and artifacts can be preserved and supported. 

With respect to a research-oriented agen da, this requires further studie s 
and meta-stud ies in the same vein of that by iMartin and Sommervillel ( 2004 ) ; 



Cabitzal (|201ll ). which aim to identify recurring and "universal" elemental oper- 



ations/behaviors. Their identification would facilitate the reuse of ways to map 
either domain- or setting-specific (operator) constructs with the APIs that the 
common platform has to expose to make the execution of operator constructs 
possible. These studies would share the assumption that leveraging general op- 
erator constructs will not impose users any specific practice or way to treat 
information (which is mainly represented in terms of operand constructs); this 
assumption seems reasonable first because the identified operations would be 
intended to be as "atomic" and elementary as possible; second, because what 
could change in any specific setting would be the practices users are familiar 
to and hence the way users would make sense of and articulate together those 
basic elements within their work. 
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7.2 For whom tolls the bell? 



In the previous section we hinted at the fact that an architecture that enables 
bricolage requires all the stakeholders to reconfigure their traditional roles to 
make the best use of it within the win-win game that both motivates and pays 
off the effort of such reconfiguration. But who are the stakeholders that are 
involved on a practical level? In this section we will just limit ourselves to the 
ones that are closer to the task-artifact entanglement! 60 !: traditional frameworks 
usually denote these as end users, key users, actors from one side of the divide; 
designers, analysts, programmers and developers, from the othei 6 "*!. 

The former ones are those that are supposed to invest an important effort in 
bricolaging with the system, in the hope that this could be paid off in terms of a 
better fit between the resulting system and their needs, and of a smaller impact 
on their traditional coordinative practices and accepted power relationships. To 
this regard, it is often argued that one should distinguish at least between the 
regular end user, and the so called "power user". This distinction, which can be 
of some value for purely analytical purposes, should yet be taken with caution 
if it is to drive the decision of "what to offer/allow to whom". The conventional 
label of power user, far from being used - as often is - to indicate a role having 
special rights in modifying the technology (like a sort of administrator, who is 
distinct from regular users for her "powers"), sho uld be rather interpreted as 
originally intended bv lBandini and Simon i.e., as an organizational or 



even more informal category that allows to distinguish end users on the basis 
of their motivations in improving the artifacts they also use, and for the com- 
petences they have acquired in understanding how things could be changed and 
why; then, power-users are not the "chosen ones" that receive the right to modify 
the application from above; but rather who, in virtue of their motivations and 
competencies, are either formally or informally delegated by their colleagues 
to the aim of taking personal care that the tool continuously evolves and fits 
the current needs of the community where it is put to work. Therefore, within 
our perspective, the difference between power and regular user fades into that 
of bricolant user: someone that can be factually involved in constructing and 
developing the bricolage, but that anyway also uses it, and hence contributes 



60 We are aware that buyers, top management executives, middle management officers, more 
or less official and institutionalized representatives of business units and their employees have 
always been part and parcel of the development process of a Corporate Information System. 
Yet, articulating the reconfiguration of the larger actor network that encompasses all these 
levels of involvement and accountability would be out of the chapter's scope, although a topic 
of compelling interest for sure. 

61 We already recalled in Section [2] that this divide has historical roots, and hence it is 
contingent and not ontological by all means. In particular, there was a time in which the 
concept of "user" stemmed from that of "programmer" (and not vice versa): this happened 
approximately in the second half of the 1950s (notably when Licklider and Engelbart were 
writing their seminal essays on the future role of IT) when the computer, which had been 
that far intended only as a mathematical instrument for which each of its users had to write 
her own code to executed when it was her turn, became a full-fledged time-sharing equip- 
ment and established itself as a business machine, o r bette r yet an electronic data-processing 
machine jO'Neilj Il992l : ICampbell-kellv and Aspravl. 120041 1 . 
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in building and consolidating related habits and conventions of usage and inter- 
pretation; in this light, also the slackest employee, with her implicit resistance 
or explicit complaint of the inadequacy of her tools, can be said to be an active 
part of the internalization of a bricolage tool within a cooperative setting, and 
hence its continuous accommodation, for the mutual interdependence between 
every node of the socio-technical network. For this reason, access to the editing 
environment should be purposely left to be regulated according to local and 
socially relevant conventions and initiatives that are just outside the scope of 
the technology itself. 

In regard to the IT practitioners: obviously abandoning the traditional view 
of rational design does not entail to get rid of designers at all; besides being 
socially impossible, this sounds also undesirable. Rather, it requires design- 
ers, business analysts and IT analysts to focus on different first class purposes 
and services to s upply, as we hinted at in Section 17.11 In Section [51 we re- 
called the work by lHartswood et all ( 2000h and hinted at the role of designers in 



terms of facilitators of the process of co-construction of both tasks and artifacts. 
A similar role has been identified, not occasionally, within the approach that 
proposes Participatory E volutionary Design as a v irtuous integration of EUD 
and Participatory Design (I Sumner and Stolzel . ll997lh Th e term "facilitator" yet 



must be taken more in the connotation first discussed by iHirschheim and Klein 



that is more as that of a catalyst within a chemical reaction that re- 



ally follows unpredictable, and above all, uncontrollable, dynamics; otherwise, 
the risk is to conceive them as professionals supposed to facilitate the process 
in whi ch computer-based systems a re finally accepted as "perfect bureaucratic 
tools" {H arris and HendersonL 19991 ) and adopted within a community of prac- 



tice or organizational setting. 

In this view, we can detect two main roles involved in IT development from 
the IT perspective, which are characterized by specific and complementary com- 
petences. One, who acts as the catalyst/facilitator mentioned above, could be 
referred as a mcweuia-designejfl. Although such a word would be pronounced 
quite similarly to that of meta-designer, its meaning would refer to a quite differ- 
ent thing. Maieuta is who perforins the art of maieutics, the Socratic approach 
where someone helps bring out implicit notions in the interlocutors' beliefs, 
mainly through a dialogic and narrative way encompassing a series of open 
questions that do not necessarily require an answer, or just help them further 
refine their understanding and become more autonomous in their expression. 
Such a designer is primarily concerned with the front-end of the enabling tech- 
nology, i.e., with the graphical and semiotic aspects of the artifacts "to be built 
and to be used" through it; in some way, also, the maieuto-designer is who is 
supposed to "close" the design process of the merely technological part and to 
pass the baton on the end users, i.e., (the bricoleurs), by helping them in find- 
ing the ways and motivations for the "in vivo" development of their artifacts 
by their own. As such, the maieuta-designer does not have to possess strong 



62 The pronunciation of this term is quite similar to that of me4a-designer, not completely 
by chance (mee'yootah vs. 'mee-tah). 
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programming or architectural skills: rather she has to be a domain expert, a 
connoisseur of how the users of a particular domain (if not particular setting) 
are used to conceiving their tools and tinkering them over time (to what ends, 
on the basis of what political and cultural drives and constraints, and the like) 
in order to help users in exploiting the available editing environment in such 
a way that their bricolage does not become an erratic process but rather it is 
sustainable over time. 

Typical technology-oriented competencies must be conversely mastered by 
the IT professionals working on and developing the platform itself, or who we 
could denote as back-end designers and programmers: these are called to the 
role of guaranteeing that the artifacts built on top of the platform can evolve 
over time, that is that the enabling environments are easy to use for as many 
actual users as possible (and not just for few management officers). This means 
to guarantee that the best software engineering techniques (e.g, modularity, 
integration of data and routines) are employed to make the platform and exposed 
environments powerful and flexible enough to allow for the bricolage activities 
at the higher level layers of the overall architecture, besides guaranteeing also 
that the platform is modular and robust enough to cope (and align) with (low 
rate) changes in the underlying infrastructure. We could say that "designing for 
unanticipated construction" could flan k (or perhaps sub stitute) the old claim 



unanticipated construction could naiiK (or pernaps su p; 
for "designing for unanticipated use" by iRobinsonl (|l993t ). 



7.3 What's outside like this? 

We have claimed that our proposal is not original in any strong sense, but 
rather it tries to reinvigorate a discourse among the current mythologies of 
system design that conceives the progressive delegation of power and control to 
end users as a feasible way to cope with increasingly co mplex socio-te chnical 
systems, supported by increasing complicated IT systems ( Latour . 1996f l. 



In the recent years a small number of frameworks have been developed to 
exhibit at least some of the more relevant characteristics of the architecture 
presented above. Among these we obviously mention the particular document- 
based information system platform that we are developing in the last few years, 



called Web of Active Documents (WO AD, ICabitza and Simonej . 20101 : Cabitza and Gesso 



1 2 llh . This is a platform endowed with two editors, one f or the construction o f 
rule- based control structures (therein called mechanisms, ICabitza et al . 2012bf) 



and one for th e construction of ope rand constructs (atomic data structures 
called datoms, ICabitza et al l2011fJ l and their spatial arrangement in docu- 
ment templates, which provides also an execution enviro nment that has been 
currently under experime ntation in the healthcare domain ( Cabitza et all . 2011a ; 
Cabitza and Gesso . 2012 ). 



The core concepts of WO AD can be summarized as follows in terms of: i) 
the information system is parcellized in a set of hyperlinked active documents 
that can be annotated in every parts and sections and be associated with any 
other document, comment and computational behavior; ii) there is no rational 
and unified data model: users define their forms in a bottom up manner and, in 
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so doing, the platform instantiates the underlying flat data structures that are 
necessary to store the content these forms will contain and to retrieve the full 
history of the process of filling in them; iii) the presentation layer is in full control 
of end users, who are called to both generate their own templates and specify 
how their appearance should change later in use under particular conditions; 
iv) execution control is rule-based. Users can define local rules that act on the 
documents' content and, as hinted above, change how documents look like (i.e., 
their physical affordances), to make themselves aware of pertinent conditions 
according to some cooperative convention or business rule like, e.g., the need to 
revise the content of a form, or to consider it provisional, or to carefully consider 
some contextual condition 63 !. 

Although WOAD has been natively conceived to allow for the degree of 
flexibility and user autonomy that we described at length above, the specialist 
literature reports also other platforms and frameworks that exh ibit similar fea- 
tures. For instance, Placeless Documents (jDourish et all . 2000) introduced the 
idea of document properties that are attached by single end users and, above all, 
properties that represent active ways to operate with documents (called active 
properties): users can add these properties to documents to make them carry 
executable code that can be invoked to control or augment their functionalities. 
This work, to our knowledge, was among the first ones to carry into the HCI 
scientific arena notions from the prototype-based object-oriented programming 
and operating system programming, like that to attach code to documents as a 
means to control their behavior and the idea to let users develop some bunches 
of runnable code to extend the system functionalities. Also in this case, users 
have a relatively small set of operations to endow their documents with to make 
them active, but are forced to conceive for any document all those operations 
that could be invoked about and upon its content. WOAD, instead, aims to 
decouple layout structures from control structures, although these can be re- 
lated to each other by means of if-then mechanisms defined over the document's 
content. 

Enabling end users to build their own documents is a common trait of re- 
cent initiatives of visual data-driven form generation; these projects are usually 
aimed at allowing users to generate even complex forms, intended as data-entry 
points to an underlying flat data structure, without particular programming 
skil ls, e.g., by means of a visual editor like Microsoft® InfoPath® as described 
in ( Mamlin et all. 2006 ), or by me ans of the Layout Mode in FileMaker Pro® 
as used in (jChen and Akavl . 120111 ). This allows to take "form design out of the 
programmers' hands and put it into the realm of content management, much 
as form-generation tools (like Ruby o n Rails or Plone's A rchetypes) aid the de- 
veloper in rapidly generating forms" ( Mamlin et al , 20061 ) and hence to address 
a specific need that so far has been raised especially by practitioners i n the 
hospital care domain (e.g., 



especially by practitioners m tne 
M iMorrison and Blackwelll 12009 ; 



. .Mamlin et al 12006. . . 
Chen and Akav , 2011 ; Cabitza et all . 2011a ) . The system described by Mamlin et al 
(120061) ^resents also the feature to associate form elements with specific rules 

UJ see e.g. ICabitza et~al l l2009fl for other examples of such conventions. 
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(expressed in the Arden Syntax), making this similar to WO AD, although the 
editor defined in this latter framework allows for the reuse of form components 
(i.e., the datoms) and for the above mentioned decoupling between layout and 
the logic-based control flow of execution (datoms vs. mechanisms). 

In the same vein, some effort has been paid by researchers to address the 
requirement of making end user really autonomous in creating their document- 
specific rul es, and this is usually enabled by means of visual and user-friendly 
tools (e.g., ICabitza and Gessd.l20l3lKrebs et al 12012}) . An even more co mpre- 
hensiv e approach to this general aim has been recently proposed bv lHarel and Marellv 
( 20031 ) in the Play framework: this latter allows users to build reactive systems 
by playing, so to say, their specifications in a performative way, that is through 
scenarios that are subsequently implemented by means of a Play-Engine that 
"plays out" the corresponding models of interaction; these are explicitly rep- 
resented in terms of multi-step control structures, what the authors call "live 
sequence charts". These are hence way more complex and articulated interac- 
tion structures than simple rules are, and we have discussed above how this is 
not necessarily a good thing to cope with unknown emergent behaviors. Yet, 
in Play it is how users can specify these models of human-computer interaction 
that is innovative and peculiarly aligned with some of the tenets we discussed 
above: end users can interact with prototype user interfaces and have the sys- 
tem build the corresponding structures, or write the intended behavior and its 
main exceptions handling procedures in brief sentences expressed in natural (yet 
structured) language, or even tell it directly to the system, in a sort of versatile 
multi-mode way to teach the system what to do if some events occur (typically 
at interface level). 

The Play framework h as been specifically proposed as a concrete first step 
toward what lHarell (|2008l) suggestively calls the liberation of programming from 
its three straightjackets: these are the "1) need to write down a program as 
a symbolic, textual, or graphical artifact; 2) the need to specify requirements 
(the what) separately from the program (the how) and to pit one against the 
other; 3) the need to structure behavior according to the system's structure, 
providing each piece or object with its full behavior" (p. 29). The aim to 
liberate programming from these representational straightjackets resonates in 
very close affinity with the tenets of a EUD approach to supporting end users 
perform bricolage in their situated practices like the one we described in this 
chapter and seems to go in the direction of drawing a common agenda where 
practitioners from different disciplines like the software engineering field, Human 
Computer Interaction and CSCW can perhaps meet together and inform their 
own research and development initiatives in a positive manner. 



8 Some final remarks for future discussions 

In this section we will just outline two important aspects that should be object 
of future research (or discussion) about the concrete applicability of the laissez- 
faire method and of the logic of bricolage (see also Listing [1]) in the development 
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and evolution of socially embedded systems. These two topics regards important 
strands of research that are receiving a crescent interest from diverse commu- 
nities of researchers involved in studying the impact of IT in social settings in 
the last years. We broadly denote these two topics as "concerns about risk" and 
"concerns about interoperability" (and hence standardization). 



8.1 How risky is a different development strategy? 

One could detect a harsh irony in our advocacy of a laissez-faire approach (that 
is, of a no method) for the construction of an efficient, effective and safe tech- 
nology, whereas it has been the need to guarantee such qualities that motivated 
the consolidation of engineering methods and methodology in IT system con- 
struction (see Section [5]). This feeling could be indeed reinforced by our explicit 
confidence that an environment enabling and supporting ateleological bricolage 
by end users could be a feasible alternative to any *-design of those systems. In- 
deed, in the specialist literature there i s a consolidated tende ncy in considering 
bricolage akin to improvisation ( Weick . 1993t LanzaraL 19991 ) and the bricoleur 



as someone, at best, who draws on the m aterials at hand to create a response to 
a task on the spot (jLevi-Strauss , Il966h : in the Lanzara's words: "in a broadly 



diffused engineering ideology, bricolage is usually associated with second- best 
solutions, maladaptation, imperfection, inefficiency, incompleteness, slowness". 
This prejudice is renovated several times within the system development dis- 
course. 

One reason for that is to be found in the misunderstanding coming from 
understating the radical novelty that the myth of the bricolant /bricoleur carries 
with itself. In fact, as long as bricolage is evoked in discourses that still refer 
to a traditional way to build computational artifacts or that even just spare 
the traditional wording (e.g., design with users, meta-design), that is as long 
as bricolage is ingrained in a traditional way to think of IT design (even in the 
light of contributions coming from participatory design, action research, and 
ethnography), we keep undermining the original sense of this concept in some 
(important) way and, worse yet for our aims, weakening its full potential to 
move into a new more useful mythology. 

From what we argued at length in Section [S] and then in this section, it 
should be clear that we stress the ability of the bricoleur to "work and play 
with the stock [with] parts that are not standardized or inv ented, [but rather] 
appropriated for new uses" (jWeinstein and Weinstein . Il99ll pp. 161-162), and 



that are taken from "an inventory of semi-defined elements [that] are at the 
same time abstract and concrete [and that] carry a meaning, given to them by 
their past uses and the bricoleur's experience, knowledge and skill, a meaning 
which can be modified, up to a point, by the requirements of the project and 
the bricoleur's intentions" ( Louridas . 1999): exactly what we above called con- 



structs. In this compositional mythology then, the concept of bricolant end user 
should not be seen any longer as an "improviser", a tinker, hobbyist or hacker 
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in the negative connotation of these termO; but rather as a creative actor who 
is exploited (however harsh this term could seem) by the sponsors of the digi- 
tization initiative to reach their purposes in the awareness that only end users 
are competent enough to reach a sustainable balance between effectiveness and 
efficiency in cooperative ambits and, above all, to meaningfully improvise in face 
of the unexpected, in virtue of the fact that users, communities and organiza- 
tions already exist (i.e., they pre-exist digitization and informating initiatives) 
and already possess "a disposition towards their environment [...,] already [are] 
commit ted in a self-meaningful m anner towards [their] own survival and pros- 
perity" (|Angell and Ilharcoll2009h . 



Supporting bricolage then is not the slothful retreat of the blase researcher 
that releases responsibility advocating a more empowered and active role of end 
users in virtue of her democratic feelings. Rather it is the ultimate strategy 
to make the complex socio-technical systems that our IT solutions contribute 
to set up more resilient in face of the normality of accidents. More than this, 
we submit that an architecture that adopts a laissez-faire method and the logic 
of bricolage described above could be said to be both intrinsically resilient and 
evolutive, two terms that are attracti ng more and more interest b y researchers 
involved in the safety of IT systems ( Hanseth and Ciborra L 2007t) espe cially in 



critical or delicate settings, like, e.g., healthcare (jHollnagel et a 1 12008ft . These 



two concepts regards the capability of a system to react or change to unexpected 
events, changes or conditions at different time scales, respectively short and long 



64 This latter connotation has been unfortunately preserved, if not even reinforced (probably 
against their intentions) by who introduced such a concept in the IT discourse, often for some 
sort of patronizing empathy with the revolutionary and yet ill-organized attitude that is 
typical of bricoleurs in front of very well structured work contexts. As paradigmatic of this 
risk, we can mention Ciborra, who is certainly one of the most inspired researchers that in 
his works referred to and discussed several times the idea of embedding bricolage strategies in 
organizations; 

As soon we leave the realm of method, procedure, and systematic ways of 
organizing and executing work according to rational study, planning, and control 
we enter the murky world of informal, worldy, and everyday modes of operation 
and practices. It is the real of hacking; practical intelligence; the artistic em- 
broidery of the prescribed procedure; the shortcut and the trasgression of the 
established organizational order as embedded in systems and formalized rou- 
tines. Bricolage, improvisation and hacking [...] all seem to share the same way 
of operating: small forces, tiny interventions, and on-the-fly add-ons lead, when 
performed skilf ully and with close attention to the local context, to momentous 
consequences JCiborral . |2002| , p. 47-48) (our emphasis). 

Thus, notwithstanding his good intentions, and acknowledging the context in which Ciborra 
provided his argumentations, i.e., a context in which information systems were rationally de- 
signed, digitization programs strictly planned and work activities tightly ordered (!), we find 
that his purposely ill-concealed sympathies for this guerrilla-like and spontaneous, istinctive, 
almo st extempore resistance of revolutionary users that sabotage the megamachine ( Latouchc , 
2004) with smart workaroun ds and i nterve ntions "that diverge from the formalized, pre- 
planned ways of operating" ((Ciborra, 2002T), and his sympathizing and benevolent gaze to 
something that Ciborra himself acknowledged being perceived derogatorily and "sanctioned 
as marginal, belonging to the red light districts of the organization", all that ended up by un- 
dermining the actually revolutionary potential of the concept of bricolaging, certainly against 
his intentions. 
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with respect to the occurrence of unexpected event. Being both resilient, that is 
able to reach a stable and safe working state after that some unexpected event 
has occurred, and evolutive, that is able to grow and increase one's own fit with 
respect to the surrounding environment, is a fundamental characteristic of socio- 
technical systems to properly face the increasing odds of failure of some of their 
multiple components as also a function of the increasing complexity of their 
interrelated parts and corresponding links. This characteristic also constitutes 
a progress within the rhetoric around safety with respect to the concept of 
robustness; this refers more to the capability of a system to resist and withstand 
adverse events and change, also in virtue of design and analysis phases usually 
aimed at identifying, prioritizing and handling specific exceptions, or at reducing 
the opportunity for their occurrence. 

The architecture we envision above is intrinsically resilient as it, paradoxi- 
cally as it can seem, delegates to end users the burden and responsibility to react 
to unexpected events by leveraging their innate creativity and the invaluable, 
and often irremediably tacit, knowledge of the overall syste m dynamics, some- 



times much more based on intuition than on rationality (jMark and Semaan , 



20081) ; and because such an architecture purposely avoids to provide users with 



information and execution structures that are constrained and articulated on 
the basis of strong assumptions on how the system will behave under certain 
conditions: a bricolage-based information system is just an environment for both 
the human and automated manipulation and processing of signj^l. Moreover, 
interactive systems that are built on top of such an architecture are naturally 
and concretely open to evolution, even more than many other ones as they, 
differently from those systems that are built by someone else than their actual 
users, are changed opportunistically by end users on their own when (or in short 
time after that) they feel this necessary to accomodate their artifacts and tools 
to emerging conditions and newly recurring situations. 
Again in the Lanzara's words: 

[...], systems assembled by bricolage have an evolutionary advantage: be- 
ing loosely connected and incoherent assemblies of mixed components, they can 
be partially reworked without much investment effort. Bricolage is a design 
strategy that makes sunk costs recoverable. In case of system's depletion, obso- 
lescence or low performance, regeneration can be done without having to throw 
away the whole structure. [. . . ] As a consequence, systems are persistent and 
robust because cannot be changed or moved easily, but at the same time keep 
structural plasticity and exhibit some self-correcting properties. Innovation can 
be accommodated locally. [. . . ] As [bricolage] exploits the properties of exist- 
ing structures for interactive and generative purposes, it successfully mediates 
the dilemmas of change and stability, innovation and conservation. On the one 
hand, by experimenting with transient constructs it allows for some variability 
and improvisation without incurring in the possible disruptions caused by exces- 
sive instability and radical change; on the other hand, by assembling robust but 
furtherly manipulable structures, it allows for some order and reliability without 
curbing the chances for system improvement and innovation. In short, it makes 
both radical innovation and complete unraveling unlikely, (p. 347) 



65 If the worst thing occurs, e.g., if power goes down, the overall socio-technical system is 
made more resilient simply by printing down some layout structures on paper and have the 
users work as usual, just without the computational augmentation of those structures. 
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We subscribe this understanding of the role that an active, conscious and 
responsible bricoler can play in system development, but also associate this 
with the awareness that new platforms must be built supporting this role, and 
new professionals must be educated to mediate between the possibly conflicting 
stances of such an empowered actor and other roles that are in a hierarchical 
relationship with it. 



8.2 Interoperability Concerns 

The second issue we propose for future research and discussion regards the 
tension between the global dimension and the local one in the construction of a 
technology aimed at supporting whole organizations and/or networks of these 
latter; this is therefore the extension of what we have discussed so far in terms 
of collaboration within groups of limited size, what we call the local dimension, 
in the new terms of interoperability "in the large", i.e., across multiple settings 
and organizations. The separation between global and local has been already 
shown as illusory by who have recently p roposed the concept of information 
infrastructure (e.g., Ellingsen et all . 2012h . as it is recognized that any local 



event or practice can have the potential to affect the overall system, sooner or 
later (cf. the butterfly effect that is often associated with complex systems). 

In Section [5] we have very briefly hinted at how this separation can be just 
seen as one way by which the interests of someone (typically institutional au- 
thorities of control and high-level regulatory bodies at Regional or National 
level) are imposed on the practices of others (typically the pro ducers of in- 
scribed data and their first consumers for articulative reasons dBerd . 11999k 



IWinthereik and Vikkelso . 2005 ; Cabitza and Simon 1 l2012bl )). Consequently, 



addressing the tension between local vs. global requirements means to also 
address one of the main root causes behind the pervasive (and still relatively 
neglected) phenomenon usually denoted as "work around"; such a circumven- 
tion of the system and its intended (and designed) uses which users perform 
to overcome the rigidity that the global view of ISs imposes on their local 
practices can indeed undermine any serious attempt t o engineer and deliver 



safe and robust technologie s in socio-technical systems (jNiazkhani et all . 12011 



Handel and Poltrockl 120111 ). In this section, we will outline how a laissez-faire 
method can be compatible with the increasing need for global interoperability 
between local systems and, in its little own, can contribute in going beyond the 
above mentioned tension by interpreting such seeming opposition (see Section[2]) 
in a more dialectical way towards the development of information systems that 
can be flexible enough to meet t he local needs of da t a prod ucers', i.e., the 
primary users of any information (jCabitza and Simon el. l2012bh . as well as the 



needs/expectations of some relevant data consumers (i.e., secondary users) at 
the same time. 

A typical solution adopted in the organizational domain is to solve the ten- 
sion between global and local needs by building technologies that are conceived 
to be part of a global infrastructure aimed at becoming the backbone enabling 
an integrated/ federated (sometime also called cooperative) management of data 
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and business processes across multiple systems: the aim of these initiatives is 
to rationalize data schemes and business processes under a unified program 
that guarantees that the requirements that really counts at global level are met 
thanks to a centralized control. If the process requires a progressive construction 
of smaller components, then the main issue at stake becomes how to guarantee 
interoperability among these components through the definition and enactment 
of standards of both data classifications and protocols for the exchange of data 
and control structures, respectively. This trend characterizes recent attention 
to the so called semantic Web and ontology-driven orchestration of services and 
processes. 

Yet, as aptly recalled bv lLanzara (1999), "anthropologist Clifford Geertz has 
pointed out that the more we try to make the world "global" the more the world 
responds with the emergence of multiple "local worlds" and identities that seem 
to be irreducible to one anoth er (Geertz, 199 6). In the same line, but with a 
more technological perspective, ICiborra (1992) suggests that "Top management 
needs to appreciate local fluctuations in system practices as a repository of 
unique innovations and commit adequate resources to their development, even if 
the systems go against traditional approaches. Rather than looking for standard 
models in the business strategy literature, [strategic information systems] should 
be sought in the theory and practice of organizational learning and innovation, 
both incremental and radical". 

We are not interested here in considering the innovation issue mentioned in 
this latter passage. Nevertheless, we believe that this passage offers an inter- 
esting stimulus to go beyond the way in which firms conceive their (strategic) 
information systems. Actually, letting information systems "[. . . ] emerge from 
the grass roots of the organization, out of end-user hacking, computing, and tin- 
kering" asks for a significant change of perspective in IT design that is closely 
related to the performative and bricolage-oriented stance we advocated in this 
chapter. Since " organizat i onal l earning and innovation" occur where practices 
are a nd action is (IDourishl . 120011 ). we subscribe the suggestion bv lCiborral (|l992T ) 
and Lanzara (1999) to start from this "local dimension" to build a technolog- 
ical support that promotes firms' vitality not only for the sake of innovation 
but also for an effective every day performance. Moreover, since "learning and 
innovation" are "both incremental and radical", the requirement of having dif- 
ferent layer dynamics (or change rate) that was discussed in Section [7] can be 
put in relation with the need to cope with incremental and radical changes in 
the organization itself and in the co-evolving technology. 

The idea we would like to be considered, discussed and above all experi- 
mented regards the "whole" not as a centralized and monolithic entity (to some 
extent); but rather as the composition of "small" entities, highly specialized to 
the local needs, tightly connected in a web of loose connections interconnect- 
ing "local spac es", i.e., peer nodes t hat are each characterized by local structure 
and semantics (jBandini et all . 120071 ) and that are easily adaptable to unexpected 
contingencies since they are concerned with (and hence control) a limited and 
well known "piece" of the world. Obviously, soon a need to make this new kind 
of "whole" coherent and consistent with the overall good performance of the 
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network would arise, which is the main concern of any higher-level management 
unit. Yet, instead of having the management promote (and enforce) coherence 
in terms of "obtrusive" control of local behaviors and top-down ontologies to or- 
der resources, the management unit itself should behave as a "local entity" with 
specific goals and expectations on data produced by other units, expressed in 
terms of its own local quality level constraints. These latter can be exposed as 
public expectations that other units can (or have to) comply with to intemper- 
ate, once either the producer or the consumer have selected what data structures 
are involved by these constraints and how these data have to be arranged and 
aggregated to respect the consumer's needs. 




Figure 5: Two ways to reach interoperability between data producers and con- 
sumers: a) through standardizing infrastructures; b) through peer-to-peer ne- 
gotiations and ad-hoc specifications. 



As we discussed in ( Cabitza and Simonei . 2012b ). interoperability can be 



achieved in two ways: either by having higher level entities require (and obtain) 
data from data producers (e.g., node 2 asking for data a, b and c to node 1 in 
Figure a, and node 3 asking for data a and b' to node 2 in the same figure), 
which is the traditional way where the global dimension of a data provision is 
obtained through a sort of trans-lation of locally produced locally data into a 
standardizing infrastructure (by means of imposed protocols, schemas and for- 
mats); or having consumer entities (which need data for secondary purposes) 
declaring interest in specific data sets that are being produced by some producer 
unit (for their primary purposes, see the letter sequences in the dashed balloons 
in Figure[Sl in both box a and b), obviously in the assumption that a list of avail- 
able data are shared by these latter ones (see the sequence of letters in the square 
balloon in box b of Figure [5]) ; the point-to-point provision between consumer 
and producer can be then enriched by two kinds of mechanisms: presentation 
mechanisms (see the function f(-) in Figur^SJfr); and affording mechanisms (see 
the function g(-) in Figur^SJfr). The former kind of mechanism is a functional 
specification of the consumer about how this would like to receive the raw data 
packed up by the producer, in terms of specific aggregation, basic processing 
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and reporting, in order to have those data more meaningful (or convenient) at 
its side. Obviously, this function can be applied by the consumer itself once the 
producer has supplied the input data, but most of the times it will be processed 
by the producer directly on the basis of data that are not necessarily exposed 
publicly (in Figure [5J b see data x, which is not published by node 1 but in 
some sense requested by node 2 in terms of a f unctional specification of dat a 
y, f(-)0 Affording mechanisms, as presented in (jCabitza and Simond . l2012bf ). 
are mechanisms dispatched by requesters in order to convey minimal expected 
quality levels to producers and make them aware of quality constraints that, if 
not complied with, could seriously undermine the secondary use of the requested 
data, e.g., to make unit 1 (in Figure [5J b understand when archival or statistical 
purposes at unit 2 are partly or totally undermined by their otherwise perfectly 
reasonable (yet idiosyncratic) ways to produce and handle data locally. In so 
doing, local units can maintain the full autonomy, as well as being endorsed by 
an explicit accountability and liability contract, with respect to how to fulfil 
data requests/requirements. This approach is naturally scalable with respect 
to higher-level management units, even outside the organization itself, whereas 
compliance with presentation mechanisms can be more or less mandatory at 
political level (still, not embedded at technological level). 

In other words, the bottom up construction of (information) structures that 
we have mentioned in Section [7] are then one way to deal with interoperability, 
as the requests from one local entity (i.e., the consumer) can be expressed as a 
sort of unstructured lists of reques ted items from those struc tures (as depicted in 
the squared balloons in Figure [5J&[S imone and Sarimll200lh . as well as of sets of 
ordering/ aggregating policie s on these latter (see dashed balloons in Figure [5j b 
Cabitza and Simone . 2012b) that another local entity (i.e., the producer, node 1 



in Figure [5J6) can employ to process/package those items and send them to the 
requester (node 2 in Figure [SJ b) . These data (or reports obtained by applying 
the presentation mechanisms) can be then reinterpreted by the receiving entity 
without the need to know anything (i.e., their situated meaning, let alone their 
upper-level meaning) about the sender' structures. 

In this scenario, interoperability is achieved not by semantically enriching 
data at the producer's side, i.e., where those data are not natively attached with 
that semantics, but rather by having consumers pragmatically express what data 
they need, subscribe to a set of data that are exposed by producers and, possibly, 
express also how they need those data be presented (i.e., reported, typically in 
aggregated form). In this view, the definition of "standa rd structures" (which 
play the role of boundary obiects lstar and Bowkeii fl999h ) end up by regarding 
much simpler pieces of information, i.e., a subset of the operand constructs of one 
unit that this latter exposes to the outside world (or to specific correspondent 
units, typically of higher level in a social hierarchy); as said above, these latter 
items can be considered as changing with a low speed rate, since they play a 
sort of minimum data set that characterizes the unit at hand, but they are 
in any case easily modifiable since they are not universally (and hence not 
rigidly) incorporated in more complex structures. In this view, consistency has 
to be obtained by an effective monitoring of the received structures, instead of 
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a prescriptive way on how to achieve interoperability about them. 



9 Conclusions 

Let every careful man be very far from writing about things truly worthy of 
care. 

(Plato, 352 BCf3 

The main claim of this paper is that, in order to bridge the gap between what 
users need and what is given to them as solutions to those needs, the concept of 
design has to be substantially challenged and its role in IT development reformu- 
lated. To this aim, we submit that an old mythology of design, which is based on 
the separation between conceptual design and situated use, and consequently 
on the modelling activity that entails this separation (see Section [5]) , should 
be abandoned in favour of a new mythology; we advocate this new mythology 
be grounded on both the notion of performativity, from the conceptual per- 
spective, and on the notion of the bricolant end user, from the more practical 
perspective. Reviewing the main tenets of this mythology has brought us to 
introducing a lean method for the development of socially embedded technolo- 
gies, epitomized by the motto " laissez faire les bricoleurs" and the preliminary 
proposal of a " logic of bricolage" that specific environments should enact to em- 
power end-users in the process of development of their tools. Quite contrarianly 
with respect to whom w elcomes the increasing blurring between the roles of 
designers and users fe.g.. iFischer et al , 2004 ; Johannessen et all 120121 ). we do 



not advocate the idea by which users should increasingly "act as designers" (and 
researchers work to that aim), as such an idea would foster the approach by 
which users adopt a spurious attitude and end by putting themselves out of the 
practice, even if temporarily: in so doing, it is a short step that users become 
people who think to "design her ow n practices" as well (as it is claimed even 
recently by I Johannessen et all 12012 ). Conversely, the role of IT professionals 



and of end-users has to be characterized by a clear separation of concerns in the 
development of computer-based supports of cooperative, organizational work: 
hard engineering-based design of meta- systems for the former ones, bricolag-mg 
for the latter ones. Indeed, we submit that this separation, that is at least 
conceptually (if not also pragmatically) opposite to proposals that advocate a 
tight integration between, if not a unification of, conceptual design and end-user 
practices (e.g., the participatory design and the meta-design frameworks) can 
have the advantage to make the relationships among these two roles not only less 
harmfully ambiguous, but also and above all, more productive with respect to 
the timely and effective deployment and maintenance of computational artifacts, 
since end-users are in full control of this process, which many contributions in 
the specialist literature recognize as highly situated and intertwined to social 
aspects that can not really be untangled from the technical ones. 

As we have mentioned in Section [7J there are examples of technologies that 
can be interpreted as steps toward the goal of letting users be in true control 
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of the technology they think to need and wish to use. At a cursory glance, 
these technologies implement different kinds of platforms that enable users to 
perform bricolage-like activities in which the pieces that these platforms make 
available are composed and arranged in meaningful ways. However, there is still 
a long way to go, in order to collect findings that would confirm that there is 
an alternative way to design than the conceptual and representational one that 
is currently ruling in our development methodologies and professional practices. 
In order to make this journey effective, we believe that the main future steps 
should reconsider some aspects that still characterize the robust stronghold of 
the mainstream mythology. 

Apart form any technical consideration, this approach would require a sub- 
stantial change in the way young IT-related students are educated to infor- 
mation system design: this is traditionally based on a plethora of data mod- 
els, from the business-oriented one (the conceptual model) up to the more 
machine-related one (the physical model) , and on a collection of business pro- 
cess models and notations by which to describe how work is (or should be) 
carried out on those data. However, from a broader perspective, the main 
role that we have advocated for the development of collaborative applications 
and information systems, namely the role of the facilitating maieuta- designer, 
would instead require an educational agenda that is quite different and way 
much less consolidated and agreed upon than the one so far conceived for the 
role of the system developer and programmer: t his would encomp ass, for in- 



stanc e, teaching the basics of so cial informatics (jKling et all . 120051 ) and semi 



otics ( de Souza and Leitaol 2009), so me qualitative research methods adapted 



to the IT domain (|Kling et a 1120051) . insights on curre nt theories on IT im 



pact and risk management (jHanseth and Ciborral . 120071). as well as notions o f 



socially-informed history of technological evolution (jAkera and Aspravl . 120041 ) . 
The point is that all three of the roles we discussed in Section [T7S1 namely the 
usej 67 ! (as expert of the setting), the facilitator (as domain expert) and the IT 
developer (as expert of infrastructural concerns) should receive a newly formu- 
lated or seriously revisited educational program s o that an effect ive way to take 



"human actors" seriously can be promoted again (jBannonl . 119921 ) . 

On the other hand, the layered conceptual architecture that we have illus- 
trated in Section[7]has still to prove its practical value, feasibility and efficacy in 
a reasonable range of application domains (or settings): our personal research 
experience makes us confident that such an architecture is promising for the 
case of document-based, knowledge-intensive collaborative (information) sys- 
tems; although many such systems can be found in the world out there, we are 
aware that this macro-class of applications simply does not cover all IT-based 
supports. In any case, in order to go a step further in this direction, better plat- 
forms and environments supporting an effective and reliable EUD approach are 
needed; we have proposed some basic principle on which these systems could all 



67 We consider also the user in this point, because also potential end-users should be invited 
to see technology as a convivial and creative tool to build and maintain over time, in their 
active responsibility, rather than as an immutable (yet mobile) commodity to passively use or 
as a consumerist gadget to possess and use well below its full potential. 



56 



be based on: decoupled modularity of information and control structures; loose 
integration of the latter ones in terms of recomposition of elemental common 
constructs according to local needs (as opposed to the construction of unifying 
general schemes) ; full homogeneity across the layers for the construction of ag- 
gregated functionalities so that users can access them and operate with them 
with the same high-level language; and finally, tools supporting the technology 
development and managing its intrinsic complexity that are based on users' 
building practices (vs. the introduction of more or less "hard" engineering tools 
in EUD). 

The three brief (and necessarily partial and unbalanced) outlines of current 
discourses on complexity, performativity and bricolage, as well as the novel (or 
not so novel) contributions of ours, like the little tale on the historicity of concep- 
tual design, the notion of task- artifact entanglement, the requirement of univer- 
satility for EUD environments, the concept of the bricolant/bricoleur end- user, 
the foundation of a logic of bricolage, the distinction between maiewto-designers 
and traditional designers (also on an educational level) , the laissez-faire method 
as conscious way to cope with socio-technical complexity, the peek to the lo- 
cal/global illusion, these are all provided as pieces of a bricolage. Like any 
bricolage, we do not see a particular truth in any of the pieces we brought to- 
gether in this chapter; rather we have argued about the potential of the resulting 
jigsaw puzzle, in our opinion coherently kept together by the mythology of the 
performative end-users, as a whole to come out being use-ful. Obviously our 
last hope is that the EUSSET forum will host many similar discourses, among 
which those picked up and assembled in this chapter, and give them some sort 
of legitimacy to inform future common initiatives of research, education and IT 
professional practice. 
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